Skip to main content

NETWORK BASICS

Network A system of interconnected computers and computerized peripherals such as printers is called computer network. This interconnection among computers facilitates information sharing among them. Computers may connect to each other by either wired or wireless media. A computer network consists of a collection of computers, printers and other equipment that is connected together so that they can communicate with each other.  


Network application
A Network application is any application running on one host and provides a communication to another application running on a different host, the application may use an existing application layer protocols such as: HTTP(e.g. the Browser and web server), SMTP(e.g. the email-client). And may be the application does not use any existing protocols and depends on the socket programming to communicate to another application. So the web application is a type of the network applications. 
There are lots of advantages from build up a network, but the th…

Troubleshooting IP, IPv6, and VLANs

The following ICND2 exam topics are covered in this chapter :
Image result for Troubleshooting IP"1 Troubleshooting
■ Identify and correct common network problems
■ Troubleshoot and Resolve routing issues
■ Routing is enabled
■ Routing table is correct
■ Correct path selection
■ Troubleshoot and resolve inter VLAN routing problems
■ Connectivity
■ Encapsulation
■ Subnet
■ Native VLAN
■ Port mode trunk status

In this chapter, especially at first, it’s going to seem like we’re 
going over lot of the same ground and concepts already cov￾ered in other chapters. The reason for this is that troubleshoot￾ing is such a major focus of the Cisco ICND1 and ICND2 objectives that I’ve got to make 
sure I’ve guided you through this vital topic in depth. If not, then I just haven’t done all 
I can to really set you up for success! So to make that happen, we’re going to thoroughly 
examine troubleshooting with IP, IPv6, and virtual LANs (VLANs) now. And I can’t stress 
the point enough that you absolutely must have a solid, fundamental understanding of IP 
and IPv6 routing as well as a complete understanding of VLANs and trunking nailed down 
tight if you’re going to win at this!
To help you do that, I’ll be using different scenarios to walk you through the Cisco 
troubleshooting steps to correctly solve the problems you’re likely to be faced with. Although 
it’s hard to tell exactly what the ICND1 and ICND2 exams will throw at you, you can 
read and completely understand the objectives so that no matter what, you’ll be prepared, 
equipped, and up to the challenge. The way to do this is by building upon a really strong 
foundation, including being skilled at troubleshooting. This chapter is precisely designed, 
and exactly what you need, to seriously help solidify your troubleshooting foundation. 
The chapters following this one will focus on EIGRP and OSPF, and each has its own 
troubleshooting section. Troubleshooting WAN protocols will be thoroughly covered in 
Chapter 7. In this chapter we’ll concentrate solely on IP, IPv6, and VLAN troubleshooting.
To find up-to-the-minute updates for this chapter, please see 
www.lammle.com/forum or the book’s web page at www.sybex.com.
Troubleshooting IP Network Connectivity
Let’s start out by taking a moment for a short and sweet review of IP routing. Always remember that when a host wants to transmit a packet, IP looks at the destination address and deter￾mines if it’s a local or remote request. If it’s determined to be a local request, IP just broadcasts 
a frame out on the local network looking for the local host using an ARP request. If it’s a 
remote request, the host sends an ARP request to the default gateway to discover the MAC 
address of the router.
Once the hosts have the default gateway address, they’ll send each packet that needs to 
be transmitted to the Data Link layer for framing, and newly framed packets are then sent 
Troubleshooting IP Network Connectivity 743
out on the local collision domain. The router will receive the frame and remove the packet 
from the frame, and IP will then parse the routing table looking for the exit interface on the 
router. If the destination is found in the routing table, it will packet-switch the packet to 
the exit interface. At this point, the packet will be framed with new source and destination 
MAC addresses.
Okay, with that short review in mind, what would you say to someone who called you say￾ing they weren’t able to get to a server on a remote network? What’s the first thing you would 
have this user do (besides reboot Windows) or that you would do yourself to test network con￾nectivity? If you came up with using the Ping program, that’s a great place to start. The Ping 
program is a great tool for finding out if a host is alive on the network with a simple ICMP 
echo request and echo reply. But being able to ping the host as well as the server doesn’t guar￾antee that all is well in the network! Keep in mind that there’s more to the Ping program than 
just being used as a quick and simple testing protocol.
To be prepared for the exam objectives, it’s a great idea to get used to connecting to 
various routers and pinging from them. Of course, pinging from a router is not as good 
as pinging from the host reporting the problem, but that doesn’t mean we can’t isolate 
problems from the routers themselves.
Let’s use Figure 18.1 as a basis to run through some troubleshooting scenarios.
F ig u re 18 .1 Troubleshooting scenario
10.1.1.1 Fa0/0 Fa0/0
Fa0/1
.1
Fa0/1
.254
172.16.20.1
10.1.1.254 172.16.20.2
10.1.1.10 172.16.20.254
PC1 Server1
192.168.10.0/24 Switch
S1 S2
R1 R2
In this first scenario, a manager calls you and says that he cannot log in to Server1 from 
PC1. Your job is to find out why and fix it. The Cisco objectives are clear on the trouble￾shooting steps you need to take when a problem has been reported, and here they are:
1. Check the cables to find out if there’s a faulty cable or interface in the mix and verify 
the interface’s statistics.
2. Make sure that devices are determining the correct path from the source to the destina￾tion. Manipulate the routing information if needed.
3. Verify that the default gateway is correct.
744 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
4. Verify that name resolution settings are correct.
5. Verify that there are no access control lists (ACLs) blocking traffic.
In order to effectively troubleshoot this problem, we’ll narrow down the possibilities by 
process of elimination. We’ll start with PC1 and verify that it’s configured correctly and 
also that IP is working correctly.
There are four steps for checking the PC1 configuration:
1. Test that the local IP stack is working by pinging the loopback address.
2. Test that the local IP stack is talking to the Data Link layer (LAN driver) by pinging 
the local IP address.
3. Test that the host is working on the LAN by pinging the default gateway.
4. Test that the host can get to remote networks by pinging remote Server1.
Let’s check out the PC1 configuration by using the ipconfig command, or ifconfig on 
a Mac:
C:\Users\Todd Lammle>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
 Connection-specific DNS Suffix . : localdomain
 Link-local IPv6 Address . . . . . : fe80::64e3:76a2:541f:ebcb%11
 IPv4 Address. . . . . . . . . . . : 10.1.1.10
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 10.1.1.1
We can also check the route table on the host with the route print command to see if it 
truly does know the default gateway:
C:\Users\Todd Lammle>route print
[output cut]
IPv4 Route Table
=======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
 0.0.0.0 0.0.0.0 10.1.1.10 10.1.1.1 10
[output cut]
Between the output of the ipconfig command and the route print command, we can 
be assured that the hosts are aware of the correct default gateway.
Troubleshooting IP Network Connectivity 745
For the Cisco objectives, it’s extremely important to be able to check and 
verify the default gateway on a host and also that this address matches the 
router’s interface!
So, let’s verify that the local IP stack is initialized by pinging the loopback address now:
C:\Users\Todd Lammle>ping 127.0.0.1
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Ping statistics for 127.0.0.1:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 0ms, Maximum = 0ms, Average = 0ms
This first output confirms the IP address and configured default gateway of the host, and 
then I verified the fact that the local IP stack is working. Our next move is to verify that the 
IP stack is talking to the LAN driver by pinging the loopback address.
C:\Users\Todd Lammle>ping 10.1.1.10
Pinging 10.1.1.10 with 32 bytes of data:
Reply from 10.1.1.10: bytes=32 time<1ms TTL=128
Reply from 10.1.1.10: bytes=32 time<1ms TTL=128
Reply from 10.1.1.10: bytes=32 time<1ms TTL=128
Reply from 10.1.1.10: bytes=32 time<1ms TTL=128
Ping statistics for 10.1.1.10:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 0ms, Maximum = 0ms, Average = 0ms
And now that we know the local stack is solid and the IP stack is communicating to the 
LAN driver, it’s time to check our local LAN connectivity by pinging the default gateway:
C:\Users\Todd Lammle>ping 10.1.1.1
746 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
Pinging 10.1.1.1 with 32 bytes of data:
Reply from 10.1.1.1: bytes=32 time<1ms TTL=128
Reply from 10.1.1.1: bytes=32 time<1ms TTL=128
Reply from 10.1.1.1: bytes=32 time<1ms TTL=128
Reply from 10.1.1.1: bytes=32 time<1ms TTL=128
Ping statistics for 10.1.1.1:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 0ms, Maximum = 0ms, Average = 0ms
Looking good! I’d say our host is in good shape. Let’s try to ping the remote server next 
to see if our host is actually getting off the local LAN to communicate remotely:
C:\Users\Todd Lammle>ping 172.16.20.254
Pinging 172.16.20.254 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 172.16.20.254:
 Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Well, looks like we’ve confirmed local connectivity but not remote connectivity, so we’re 
going to have to dig deeper to isolate our problem. But first, and just as important, it’s key 
to make note of what we can rule out at this point:
1. The PC is configured with the correct IP address and the local IP stack is working.
2. The default gateway is configured correctly and the PC’s default gateway configuration 
matches the router interface IP address.
3. The local switch is working because we can ping through the switch to the router.
4. We don’t have a local LAN issue, meaning our Physical layer is good because we can 
ping the router. If we couldn’t ping the router, we would need to verify our physical 
cables and interfaces. 
Let’s see if we can narrow the problem down further using the traceroute command:
C:\Users\Todd Lammle>tracert 172.16.20.254
Troubleshooting IP Network Connectivity 747
Tracing route to 172.16.20.254 over a maximum of 30 hops
 1 1 ms 1 ms <1 ms 10.1.1.1
 2 * * * Request timed out.
 3 * * * Request timed out.
Well, we didn’t get beyond our default gateway, so let’s go over to R2 and see if we can 
talk locally to the server:
R2#ping 172.16.20.254
Pinging 172.16.20.254 with 32 bytes of data:
Reply from 172.16.20.254: bytes=32 time<1ms TTL=128
Reply from 172.16.20.254: bytes=32 time<1ms TTL=128
Reply from 172.16.20.254: bytes=32 time<1ms TTL=128
Reply from 172.16.20.254: bytes=32 time<1ms TTL=128
Ping statistics for 172.16.20.254:
 Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Okay, we just eliminated a local LAN problem by connecting to Server1 from the R2 
router, so we’re good there. Let’s summarize what we know so far:
1. PC1 is configured correctly.
2. The switch located on the 10.1.1.0 LAN is working.
3. PC1’s default gateway is configured correctly.
4. R2 can communicate to the Server1 so we don’t have a remote LAN issue. 
But something is still clearly wrong, so what should we check now? Now would be a 
great time to verify the Server1 IP configuration and make sure the default gateway is con￾figured correctly. Let’s take a look:
C:\Users\Server1>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
 Connection-specific DNS Suffix . : localdomain
 Link-local IPv6 Address . . . . . : fe80::7723:76a2:e73c:2acb%11
748 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
 IPv4 Address. . . . . . . . . . . : 172.16.20.254
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 172.16.20.1
Okay—the Server1 configuration looks good and the R2 router can ping the server, so 
it seems that the server’s local LAN is solid, the local switch is working, and there are no 
cable or interface issues. But let’s zoom in on interface Fa0/0 on R2 and talk about what to 
expect if there were errors on this interface:
R2#sh int fa0/0
FastEthernet0/0 is up, line protocol is up
[output cut]
 Full-duplex, 100Mb/s, 100BaseTX/FX
 ARP type: ARPA, ARP Timeout 04:00:00
 Last input 00:00:05, output 00:00:01, output hang never
 Last clearing of "show interface" counters never
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 1325 packets input, 157823 bytes
 Received 1157 broadcasts (0 IP multicasts)
 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
 0 watchdog
 0 input packets with dribble condition detected
 2294 packets output, 244630 bytes, 0 underruns
 0 output errors, 0 collisions, 3 interface resets
 347 unknown protocol drops
 0 babbles, 0 late collision, 0 deferred
 4 lost carrier, 0 no carrier
 0 output buffer failures, 0 output buffers swapped out
You’ve got to be able to analyze interface statistics to find problems there if they exist, so 
let’s pick out the important factors relevant to meeting that challenge effectively now.
Speed and duplex settings Good to know that the most common cause of interface errors 
is a mismatched duplex mode between two ends of an Ethernet link. This is why it’s so 
important to make sure that the switch and its hosts (PCs, router interfaces, etc.) have the 
same speed setting. If not, they just won’t connect. And if they have mismatched duplex 
settings, you’ll receive a legion of errors, which cause nasty performance issues, intermit￾tent connectivity—even total loss of communication!
Troubleshooting IP Network Connectivity 749
Using autonegotiation for speed and duplex is a very common practice, and it’s enabled by 
default. But if this fails for some reason, you’ll have to set the configuration manually like this:
Switch(config)#int gi0/1
Switch(config-if)#speed ?
 10 Force 10 Mbps operation
 100 Force 100 Mbps operation
 1000 Force 1000 Mbps operation
 auto Enable AUTO speed configuration
Switch(config-if)#speed 1000
Switch(config-if)#duplex ?
 auto Enable AUTO duplex configuration
 full Force full duplex operation
 half Force half-duplex operation
Switch(config-if)#duplex full
If you have a duplex mismatch, a telling sign is that the late collision counter will increment.
Input queue drops If the input queue drops counter increments, this signifies that more 
traffic is being delivered to the router that it can process. If this is consistently high, try to 
determine exactly when these counters are increasing and how the events relate to CPU 
usage. You’ll see the ignored and throttle counters increment as well.
Output queue drops This counter indicates that packets were dropped due to interface 
congestion, leading to packet drops and queuing delays. When this occurs, applications 
like VoIP will experience performance issues. If you observe this constantly incrementing, 
consider QoS.
Input errors Input errors often indicate high errors such as CRCs. This can point to cabling 
problems, hardware issues, or duplex mismatches. 
Output errors This is the total number of frames that the port tried to transmit when an 
issue such as a collision occurred.
We’re going to move on in our troubleshooting process of elimination by analyzing the 
routers’ actual configurations. Here’s R1’s routing table:
R1>sh ip route
[output cut]
Gateway of last resort is 192.168.10.254 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.10.254
 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.1.0/24 is directly connected, FastEthernet0/0
L 10.1.1.1/32 is directly connected, FastEthernet0/0
750 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.10.0/24 is directly connected, FastEthernet0/1
L 192.168.10.1/32 is directly connected, FastEthernet0/1
This actually looks pretty good! Both of our directly connected networks are in the table 
and we can confirm that we have a default route going to the R2 router. So now let’s verify 
the connectivity to R2 from R1: 
R1>sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.1.1.1 YES manual up up
FastEthernet0/1 192.168.10.1 YES manual up up
Serial0/0/0 unassigned YES unset administratively down down
Serial0/1/0 unassigned YES unset administratively down down
R1>ping 192.168.10.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
This looks great too! Our interfaces are correctly configured with the right IP address 
and the Physical and Data Link layers are up. By the way, I also tested layer 3 connectivity 
by pinging the R2 Fa0/1 interface.
Since everything looks good so far, our next step is to check into the status of R2’s 
interfaces:
R2>sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 172.16.20.1 YES manual up up
FastEthernet0/1 192.168.10.254 YES manual up up
R2>ping 192.168.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Well, everything still checks out at this point. The IP addresses are correct and the Physical 
and Data Link layers are up. I also tested the layer 3 connectivity with a ping to R1, so we’re 
all good so far. We’ll examine the routing table next:
R2>sh ip route
[output cut]
Gateway of last resort is not set
 10.0.0.0/24 is subnetted, 1 subnets
Troubleshooting IP Network Connectivity 751
S 10.1.1.0 is directly connected, FastEthernet0/0
 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.20.0/24 is directly connected, FastEthernet0/0
L 172.16.20.1/32 is directly connected, FastEthernet0/0
 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.10.0/24 is directly connected, FastEthernet0/1
L 192.168.10.254/32 is directly connected, FastEthernet0/1
Okay—we can see that all our local interfaces are in the table, as well as a static route 
to the 10.1.1.0 network. But do you see the problem? Look closely at the static route. The 
route was entered with an exit interface of Fa0/0, and the path to the 10.1.1.0 network is 
out Fa0/1! Aha! We’ve found our problem! Let’s fix R2:
R2#config t
R2(config)#no ip route 10.1.1.0 255.255.255.0 fa0/0
R2(config)#ip route 10.1.1.0 255.255.255.0 192.168.10.1
That should do it. Let’s verify from PC1:
C:\Users\Todd Lammle>ping 172.16.20.254
Pinging 172.16.20.254 with 32 bytes of data:
Reply from 172.16.20.254: bytes=32 time<1ms TTL=128
Reply from 172.16.20.254: bytes=32 time<1ms TTL=128
Reply from 172.16.20.254: bytes=32 time<1ms TTL=128
Reply from 172.16.20.254: bytes=32 time<1ms TTL=128
Ping statistics for 172.16.20.254
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 0ms, Maximum = 0ms, Average = 0ms
Our snag appears to be solved, but just to make sure, we really need to verify with a 
higher-level protocol like Telnet: 
C:\Users\Todd Lammle>telnet 172.16.20.254
Connecting To 172.16.20.254...Could not open connection to the host, on 
port 23: Connect failed
Okay, that’s not good! We can ping to the Server1, but we can’t telnet to it. In the past, 
I’ve verified that telnetting to this server worked, but it’s still possible that we have a failure 
on the server side. To find out, let’s verify our network first, starting at R1:
R1>ping 172.16.20.254
Type escape sequence to abort.
752 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
Sending 5, 100-byte ICMP Echos to 172.16.20.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R1>telnet 172.16.20.254
Trying 172.16.20.254 ...
% Destination unreachable; gateway or host down
This is some pretty ominous output! Let’s try from R2 and see what happens:
R2#telnet 172.16.20.254
Trying 172.16.20.254 ... Open
User Access Verification
Password:
Oh my—I can ping the server from a remote network, but I can’t telnet to it, but the 
local router R2 can! These factors eliminate the server being a problem since I can telnet to 
the server when I’m on the local LAN.
And we know we don’t’ have a routing problem because we fixed that already. So what’s 
next? Let’s check to see if there’s an ACL on R2:
R2>sh access-lists
Extended IP access list 110
 10 permit icmp any any (25 matches)
Seriously? What a loopy access list to have on a router! This ridiculous list permits 
ICMP, but that’s it. It denies everything except ICMP due to the implicit deny ip any any
at the end of every ACL. But before we uncork the champagne, we need to see if this foolish 
list has been applied to our interfaces on R2 to confirm that this is really our problem:
R2>sh ip int fa0/0
FastEthernet0/0 is up, line protocol is up
 Internet address is 172.16.20.1/24
 Broadcast address is 255.255.255.255
 Address determined by setup command
 MTU is 1500 bytes
 Helper address is not set
 Directed broadcast forwarding is disabled
 Outgoing access list is 110
 Inbound access list is not set
Troubleshooting IP Network Connectivity 753
There it is—that’s our problem all right! In case you’re wondering why R2 could telnet 
to Server1, it’s because an ACL filters only packets trying to go through the router—not 
packets generated at the router. Let’s get to work and fix this: 
R2#config t
R2(config)#no access-list 110
I just verified that I can telnet from PC1 to Server1, but let’s try telnetting from R1 again:
R1#telnet 172.16.20.254
Trying 172.16.20.254 ... Open
User Access Verification
Password:
Nice—looks like we’re set, but what about using the name?
R1#telnet Server1
Translating "Server1"...domain server (255.255.255.255)
% Bad IP address or host name
Well, we’re not all set just yet. Let’s fix R1 so that it can provide name resolution:
R1(config)#ip host Server1 172.16.20.254
R1(config)#^Z
R1#telnet Server1
Trying Server1 (172.16.20.254)... Open
User Access Verification
Password:
Great—things are looking good from the router, but if the customer can’t telnet to the 
remote host using the name, we’ve got to check the DNS server to confirm connectivity and 
for the correct entry to the server. Another option would be to configure the local host table 
manually on PC1.
The last thing to do is to check the server to see if it’s responding to HTTP requests via 
the telnet command, believe it or not! Here’s an example:
R1#telnet 172.16.20.254 80
Trying 172.16.20.254, 80 ... Open
754 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
Yes—finally! Server1 is responding to requests on port 80, so we’re in the clear. Now, let’s 
mix things up a little by adding IPv6 to our network and work through the same trouble￾shooting steps.
Troubleshooting IPv6 Network 
Connectivity
I’m going to be straight with you: there isn’t a lot that’s going to be much different 
between this section and the process you just went through with the IPv4 troubleshooting 
steps. Except regarding the addressing of course! So other than that key factor, we’ll take 
the same approach, using Figure 18.2, specifically because I really want to highlight the 
differences associated with IPv6. So the problem scenario I’m going to use will also stay 
the same: PC1 cannot communicate to Server1.
I want to point out that this is not an “introduction to IPv6” chapter, so I’m assuming 
you’ve got some IPv6 fundamentals down.
F ig u re 18 . 2 IPv6 troubleshooting scenario
Fa0/0 Fa0/0
Fa0/1 Fa0/1
2001:db8:3c4d:1:21a:6dff:fe37:a443
Fe80::21a:6dff:fe64:9b2
PC1 Server1
2001:db8:3c4d:3:ac3b:2ef:1823:8938 2001:db8:3c4d:1:a14c:8c33:2d1:be3d
2001:db8:3c4d:2::64 Switch
S1 S2
R1 R2
2001:db8:3c4d:2:21a:6dff:fe37:a44f
Fe80::21a:6dff:fe37:a44f
2001:db8:3c4d:2:21a:6dff:fe64:9b3
Fe80::21a:6dff:fe64:9b3
2001:db8:3c4d:3:21a:6dff:fe37:a44e
Fe80::21a:6dff:fe37:a44e
Notice that I documented both the link-local and global addresses assigned to each 
router interface in Figure 18.2. We need both in order to troubleshoot, so right away, you 
can see that things get a bit more complicated because of the longer addresses and the fact 
that there are multiple addresses per interface involved!
But before we start troubleshooting the IPv6 network in Figure 18.2, I want to 
refresh your memory on the ICMPv6 protocol, which is an important protocol in our 
troubleshooting arsenal.
Visit ccna 
.gg/ch18/a
for a 
companion 
MicroNugget 
from CBT 
Nuggets.
Troubleshooting IPv6 Network Connectivity 755
ICMPv6
IPv4 used the ICMP workhorse for lots of tasks, including error messages like destination 
unreachable and troubleshooting functions like Ping and Traceroute. ICMPv6 still does 
those things for us, but unlike its predecessor, the v6 flavor isn’t implemented as a separate 
layer 3 protocol. Instead, it’s an integrated part of IPv6 and is carried after the basic IPv6 
header information as an extension header. 
ICMPv6 is used for router solicitation and advertisement, for neighbor solicitation and 
advertisement (i.e., finding the MAC addresses for IPv6 neighbors), and for redirecting the 
host to the best router (default gateway).
Neighbor Discovery (NDP)
ICMPv6 also takes over the task of finding the address of other devices on the local link. 
The Address Resolution Protocol is used to perform this function for IPv4, but that’s been 
renamed Neighbor Discovery (ND or NDP) in ICMPv6. This process is now achieved via 
a multicast address called the solicited node address because all hosts join this multicast 
group upon connecting to the network.
Neighbor discovery enables these functions:
uu Determining the MAC address of neighbors
uu Router solicitation (RS) FF02::2
uu Router advertisements (RA) FF02::1
uu Neighbor solicitation (NS)
uu Neighbor advertisement (NA)
uu Duplicate address detection (DAD)
The part of the IPv6 address designated by the 24 bits farthest to the right is added 
to the end of the multicast address FF02:0:0:0:0:1:FF/104. When this address is queried, 
the corresponding host will send back its layer 2 address. Devices can find and keep track 
of other neighbor devices on the network in pretty much the same way. When I talked 
about RA and RS messages earlier in the CCENT chapters, and told you that they use 
multicast traffic to request and send address information, that too is actually a function 
of ICMPv6—specifically, neighbor discovery. 
In IPv4, the protocol IGMP was used to allow a host device to tell its local router that 
it was joining a multicast group and would like to receive the traffic for that group. This 
IGMP function has been replaced by ICMPv6, and the process has been renamed multicast 
listener discovery.
With IPv4, our hosts could have only one default gateway configured, and if that router 
went down we had to fix the router, change the default gateway, or run some type of vir￾tual default gateway with other protocols created as a solution for this inadequacy in IPv4. 
Figure 18.3 shows how IPv6 devices find their default gateways using neighbor discovery.
756 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
F ig u re 18 . 3 Router solicitation (RS) and router advertisement (RA)
FF02::1 Use me! (RA)
Internet
Corp
Corp2 FF02::1 Use me! (RA)
FF02::2 All routers respond! (RS)
IPv6 hosts send a router solicitation (RS) onto their data link asking for all routers to 
respond, and they use the multicast address FF02::2 to achieve this. Routers on the same 
link respond with a unicast to the requesting host, or with a router advertisement (RA) 
using FF02::1.
But that’s not all! Hosts also can send solicitations and advertisements between them￾selves using a neighbor solicitation (NS) and neighbor advertisement (NA), as shown in 
Figure 18.4. 
F ig u re 18 . 4 Neighbor solicitation (NS) and neighbor advertisement (NA)
NDP: NS
I need your MAC!
NDP: NA
Here is my MAC
Remember that RA and RS gather or provide information about routers and NS and NA 
gather information about hosts. Also, remember that a “neighbor” is a host on the same 
data link or VLAN.
With that foundation review in mind, here are the troubleshooting steps we’ll progress 
through in our investigation:
1. Check the cables because there might be a faulty cable or interface. Verify interfacs 
statistics.
2. Make sure that devices are determining the correct path from the source to the destina￾tion. Manipulate the routing information if needed.
3. Verify that the default gateway is correct.
Troubleshooting IPv6 Network Connectivity 757
4. Verify that name resolution settings are correct, and especially for IPv6, make sure the 
DNS server is reachable via IPv4 and IPv6.
5. Verify that there are no ACLs that are blocking traffic.
In order to troubleshoot this problem, we’ll use the same process of elimination, beginning 
with PC1. We must verify that it’s configured correctly and that IP is working properly. Let’s 
start by pinging the loopback address to verify the IPv6 stack:
C:\Users\Todd Lammle>ping ::1
Pinging ::1 with 32 bytes of data:
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Well, the IPv6 stack checks out, so let’s ping the Fa0/0 of R1, which PC1 is directly 
connected to on the same LAN, starting with the link-local address:
C:\Users\Todd Lammle>ping fe80::21a:6dff:fe37:a44e
Pinging fe80:21a:6dff:fe37:a44e with 32 bytes of data:
Reply from fe80::21a:6dff:fe37:a44e: time<1ms
Reply from fe80::21a:6dff:fe37:a44e: time<1ms
Reply from fe80::21a:6dff:fe37:a44e: time<1ms
Reply from fe80::21a:6dff:fe37:a44e: time<1ms
Next, we’ll ping the global address on Fa0/0:
C:\Users\Todd Lammle>ping 2001:db8:3c4d:3:21a:6dff:fe37:a44e
Pinging 2001:db8:3c4d:3:21a:6dff:fe37:a44e with 32 bytes of data:
Reply from 2001:db8:3c4d:3:21a:6dff:fe37:a44e: time<1ms
Reply from 2001:db8:3c4d:3:21a:6dff:fe37:a44e: time<1ms
Reply from 2001:db8:3c4d:3:21a:6dff:fe37:a44e: time<1ms
Reply from 2001:db8:3c4d:3:21a:6dff:fe37:a44e: time<1ms
Okay—looks like PC1 is configured and working on the local LAN to the R1 router, so 
we’ve confirmed the Physical, Data Link, and Network layers between the PC1 and the R1 
router Fa0/0 interface. 
Our next move is to check the local connection on Server1 to the R2 router to verify that 
LAN. First we’ll ping the link-local address of the router from Server1:
C:\Users\Server1>ping fe80::21a:6dff:fe64:9b2
758 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
Pinging fe80::21a:6dff:fe64:9b2 with 32 bytes of data:
Reply from fe80::21a:6dff:fe64:9b2: time<1ms
Reply from fe80::21a:6dff:fe64:9b2: time<1ms
Reply from fe80::21a:6dff:fe64:9b2: time<1ms
Reply from fe80::21a:6dff:fe64:9b2: time<1ms
And next, we’ll ping the global address of Fa0/0 on R2:
C:\Users\Server1>ping 2001:db8:3c4d:1:21a:6dff:fe37:a443
Pinging 2001:db8:3c4d:1:21a:6dff:fe37:a443 with 32 bytes of data:
Reply from 2001:db8:3c4d:1:21a:6dff:fe37:a443: time<1ms
Reply from 2001:db8:3c4d:1:21a:6dff:fe37:a443: time<1ms
Reply from 2001:db8:3c4d:1:21a:6dff:fe37:a443: time<1ms
Reply from 2001:db8:3c4d:1:21a:6dff:fe37:a443: time<1ms
Let’s quickly summarize what we know at this point:
1. By using the ipconfig /all command on PC1 and Server1, I was able to document 
their global and link-local IPv6 addresses.
2. We know the IPv6 link-local addresses of each router interface.
3. We know the IPv6 global address of each router interface.
4. We can ping from PC1 to router R1’s Fa0/0 interface.
5. We can ping from Server1 to router R2’s Fa0/0 interface.
6. We can eliminate a local problem on both LANs.
From here, we’ll go to PC1 and see if we can route to Server1:
C:\Users\Todd Lammle>tracert 2001:db8:3c4d:1:a14c:8c33:2d1:be3d
Tracing route to 2001:db8:3c4d:1:a14c:8c33:2d1:be3d over a maximum of 30 hops
 1 Destination host unreachable.
Okay, now that’s not good. Looks like we might have a routing problem. And on this little 
network, we’re doing static IPv6 routing, so getting to the bottom of things will definitely take 
a little effort! But before we start looking into our potential routing issue, let’s check the link 
between R1 and R2. We’ll ping R2 from R1 to test the directly connected link.
The first thing you need to do before attempting to ping between routers is verify your 
addresses—yes, verify them again! Let’s check out both routers, then try pinging from R1 
to R2: 
R1#sh ipv6 int brief
FastEthernet0/0 [up/up]
Troubleshooting IPv6 Network Connectivity 759
 FE80::21A:6DFF:FE37:A44E
 2001:DB8:3C4D:3:21A:6DFF:FE37:A44E
FastEthernet0/1 [up/up]
 FE80::21A:6DFF:FE37:A44F
 2001:DB8:3C4D:2:21A:6DFF:FE37:A44F
R2#sh ipv6 int brief
FastEthernet0/0 [up/up]
 FE80::21A:6DFF:FE64:9B2
 2001:DB8:3C4D:1:21A:6DFF:FE37:A443
FastEthernet0/1 [up/up]
 FE80::21A:6DFF:FE64:9B3
 2001:DB8:3C4D:2:21A:6DFF:FE64:9B3
R1#ping 2001:DB8:3C4D:2:21A:6DFF:FE64:9B3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to ping 2001:DB8:3C4D:2:21A:6DFF:FE64:9B3, timeout 
is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/2/8 ms
In the preceding output, you can see that I now have the IPv6 addresses for both the R1 and 
R2 directly connected interfaces. The output also shows that I used the Ping program to verify 
layer 3 connectivity. Just as with IPv4, we need to resolve the logical (IPv6) address to a MAC 
address in order to communicate on the local LAN. But unlike IPv4, IPv6 doesn’t use ARP—it 
uses ICMPv6 neighbor solicitations instead—so after the successful ping, we can now see the 
neighbor resolution table on R1:
R1#sh ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
FE80::21A:6DFF:FE64:9B3 0 001a.6c46.9b09 DELAY Fa0/1
2001:DB8:3C4D:2:21A:6DFF:FE64:9B3 0 001a.6c46.9b09 REACH Fa0/1
Let’s take a minute to talk about the possible states that a resolved address shows us:
INCMP (incomplete) Address resolution is being performed on the entry. A neighbor 
solicitation message has been sent, but the neighbor message has not yet been received.
REACH (reachable) Positive confirmation has been received confirming that the path to 
the neighbor is functioning correctly. REACH is good!
STALE The state is STALE when the interface has not communicated within the neighbor 
reachable time frame. The next time the neighbor communicates, the state will change back 
to REACH.
760 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
DELAY Occurs after the STALE state, when no reachability confirmation has been received 
within what’s known as the DELAY_FIRST_PROBE_TIME. This means that the path was 
functioning but it hasn’t had communication within the neighbor reachable time frame.
PROBE When in PROBE state, the configured interface is resending a neighbor solicitation and waiting for a reach-ability confirmation from a neighbor. 
We can verify our default gateway with IPv6 with the ipconfig command like this:
C:\Users\Todd Lammle>ipconfig
 Connection-specific DNS Suffix . : localdomain
 IPv6 Address. . . . . . . . . . . : 2001:db8:3c4d:3:ac3b:2ef:1823:8938
 Temporary IPv6 Address. . . . . . : 2001:db8:3c4d:3:2f33:44dd:211:1c3d
 Link-local IPv6 Address . . . . . : fe80::ac3b:2ef:1823:8938%11
 IPv4 Address. . . . . . . . . . . : 10.1.1.10
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : Fe80::21a:6dff:fe37:a44e%11
 10.1.1.1
It’s important to understand that the default gateway will be the link-local address of the 
router, and in this case, we can see that the address the host learned is truly the link-local 
address of the Fa0/0 interface of R1. The %11 is just used to identify an interface and isn’t 
used as part of the IPv6 address.
Temporary IPv6 Addresses
The temporary IPv6 address, listed under the unicast IPv6 address as, “2001:db8:3c4d:3:2f3
3:44dd:211:1c3d,” was created by Windows to provide privacy from the EUI-64 format. This 
creates a global address from your host without using your MAC address by generating a 
random number for the interface and hashing it, which is then appended to the /64 prefix 
from the router. You can disable this feature with the following commands:
netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set privacy state-disabled
In addition to the ipconfig command, we can use the command netsh interface ipv6 
show neighbor to verify our default gateway address:
C:\Users\Todd Lammle>netsh interface ipv6 show neighbor
[output cut]
Troubleshooting IPv6 Network Connectivity 761
Interface 11: Local Area Connection
Internet Address Physical Address Type
-------------------------------------------- ----------------- -----------
2001:db8:3c4d:3:21a:6dff:fe37:a44e 00-1a-6d-37-a4-4e (Router)
Fe80::21a:6dff:fe37:a44e 00-1a-6d-37-a4-4e (Router)
ff02::1 33-33-00-00-00-01 Permanent
ff02::2 33-33-00-00-00-02 Permanent
ff02::c 33-33-00-00-00-0c Permanent
ff02::16 33-33-00-00-00-16 Permanent
ff02::fb 33-33-00-00-00-fb Permanent
ff02::1:2 33-33-00-01-00-02 Permanent
ff02::1:3 33-33-00-01-00-03 Permanent
ff02::1:ff1f:ebcb 33-33-ff-1f-eb-cb Permanent
I’ve checked the default gateway addresses on Server1 and they are cor￾rect. They should be, because this is provided directly from the router with 
an ICMPv6 RA (router advertisement) message. The output for that verifi￾cation is not shown.
Let’s establish the information we have right now:
1. Our PC1 and Server1 configurations are working and have been verified.
2. The LANs are working and verified, so there is no Physical layer issue. 
3. The default gateways are correct.
4. The link between the R1 and R2 routers is working and verified.
So all this tells us is that it’s now time to check our routing tables! We’ll start with the 
R1 router:
R1#sh ipv6 route
C 2001:DB8:3C4D:2::/64 [0/0]
 via FastEthernet0/1, directly connected
L 2001:DB8:3C4D:2:21A:6DFF:FE37:A44F/128 [0/0]
 via FastEthernet0/1, receive
C 2001:DB8:3C4D:3::/64 [0/0]
 via FastEthernet0/0, directly connected
L 2001:DB8:3C4D:3:21A:6DFF:FE37:A44E/128 [0/0]
 via FastEthernet0/0, receive
L FF00::/8 [0/0]
 via Null0, receive
762 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
All we can see in the output is the two directly connected interfaces configured on the 
router, and that won’t help us send IPv6 packets to the 2001:db8:3c4d:1::/64 subnet off of 
Fa0/0 on R2. So let’s find out what R2 can tell us:
R2#sh ipv6 route
C 2001:DB8:3C4D:1::/64 [0/0]
 via FastEthernet0/0, directly connected
L 2001:DB8:3C4D:1:21A:6DFF:FE37:A443/128 [0/0]
 via FastEthernet0/0, receive
C 2001:DB8:3C4D:2::/64 [0/0]
 via FastEthernet0/1, directly connected
L 2001:DB8:3C4D:2:21A:6DFF:FE64:9B3/128 [0/0]
 via FastEthernet0/1, receive
S 2001:DB8:3C4D:3::/64 [1/0]
 via 2001:DB8:3C4D:2:21B:D4FF:FE0A:539
L FF00::/8 [0/0]
 via Null0, receive
Now we’re talking—that tells us a lot more than R1’s table did! We have both of our 
directly connected configured LANs, Fa0/0 and Fa0/1, right there in the routing table, as 
well as a static route to 2001:DB8:3C4D:3::/64, which is the remote LAN Fa0/0 off of R1, 
which is good. Now let’s fix the route problem on R1 by adding a route that gives us access 
to the Server1 network and then move on to VLANs and trunking:
R1(config)#ipv6 route ::/0 fastethernet 0/1 FE80::21A:6DFF:FE64:9B3
I want to point out that I didn’t need to make the default route as difficult as I did. I 
entered both the exit interface and next-hop link-local address when just the exit interface 
or next-hop global addresses would be mandatory, but not the link-local.
Next, we’ll verify that we can now ping from PC1 to Server1:
C:\Users\Todd Lammle>ping 2001:db8:3c4d:1:a14c:8c33:2d1:be3d
Pinging 2001:db8:3c4d:1:a14c:8c33:2d1:be3d with 32 bytes of data:
Reply from 2001:db8:3c4d:1:a14c:8c33:2d1:be3d: time<1ms
Reply from 2001:db8:3c4d:1:a14c:8c33:2d1:be3d: time<1ms
Reply from 2001:db8:3c4d:1:a14c:8c33:2d1:be3d: time<1ms
Reply from 2001:db8:3c4d:1:a14c:8c33:2d1:be3d: time<1ms
Sweet—we’re looking golden with this particular scenario! But know that it is still 
possible to have name resolution issues. If that were the case, you would just need to 
check your DNS server or local host table.
Moving on in the same way we did in the IPv4 troubleshooting section, it’s a good time 
to check into your ACLs, especially if you’re still having a problem after troubleshooting 
Troubleshooting VLAN Connectivity 763
all your local LANs and all other potential routing issues. To do that, just use the show 
ipv6 access-lists command to verify all configured ACLs on a router and the show ipv6 
interface command to verify if an ACL is attached to an interface. Once you’ve confirmed 
that your ACLs all make sense, you’re good to go!
Troubleshooting VLAN Connectivity
You know by now that VLANs are used to break up broadcast domains in a layer 2 
switched network. You’ve also learned that we assign ports on a switch into a VLAN 
broadcast domain by using the switchport access vlan command.
The access port carries traffic for a single VLAN that the port is a member of. If mem￾bers of one VLAN want to communicate to members in the same VLAN that are located 
on a different switch, then a port between the two switches needs to be either configured 
to be a member of this single VLAN or configured as a trunk link, which passes information on all VLANs by default.
We’re going to use Figure 18.5 to reference as we go through the procedures for troubleshooting VLAN and trunking.
F ig u re 18 .5 VLAN connectivity
Gi0/14
Gi0/1 Gi0/2
PC2
VLAN 10
192.168.10.2
PC1
VLAN 10
192.168.10.1
Gi0/3
Gi0/14
Gi0/13 Gi0/13
VLAN 10
192.168.10.3
S1 S2
PC3
I’m going to begin with VLAN troubleshooting and then move on to trunk troubleshooting.
VLAN Troubleshooting
A couple of key times to troubleshoot VLANs are when and if you lose connectivity between 
hosts and when you’re configuring new hosts into a VLAN but they’re not working.
Here are the steps we’ll follow to troubleshoot VLANs:
1. Verify the VLAN database on all your switches.
2. Verify your content addressable memory (CAM) table.
3. Verify that your port VLAN assignments are configured correctly.
764 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
And here’s a list of the commands we’ll be using in the following sections:
Show vlan
Show mac address-table
Show interfaces interface switchport
switchport access vlan vlan
VLAN Troubleshooting Scenario
A manager calls and says they can’t communicate to the new sales team member that just 
connected to the network. How would you proceed to solve this issue? Well, because the 
sales hosts are in VLAN 10, we’ll begin with step 1 and verify that our databases on both 
switches are correct.
First, I’ll use the show vlan or show vlan brief command to check if the expected 
VLAN is actually in the database. Here’s a look at the VLAN database on S1:
S1#sh vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/3, Gi0/4, Gi0/5, Gi0/6
 Gi0/7, Gi0/8, Gi0/9, Gi0/10
 Gi0/11, Gi0/12, Gi0/13, Gi0/14
 Gi0/15, Gi0/16, Gi0/17, Gi0/18
 Gi0/19, Gi0/20, Gi0/21, Gi0/22
 Gi0/23, Gi0/24, Gi0/25, Gi0/26
 Gi0/27, Gi0/28
10 Sales active Gi0/1, Gi0/2
20 Accounting active
26 Automation10 active
27 VLAN0027 active
30 Engineering active
170 VLAN0170 active
501 Private501 active
502 Private500 active
[output cut]
This output shows that VLAN 10 is in the local database and that Gi0/1 and Gi0/2 are 
associated to VLAN 10.
So next, we’ll go to step 2 and verify the CAM with the show mac address-table
command:
S1#sh mac address-table
Troubleshooting VLAN Connectivity 765
 Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
 All 0100.0ccc.cccc STATIC CPU
[output cut]
 1 000d.2830.2f00 DYNAMIC Gi0/24
 1 0021.1c91.0d8d DYNAMIC Gi0/13
 1 0021.1c91.0d8e DYNAMIC Gi0/14
 1 b414.89d9.1882 DYNAMIC Gi0/17
 1 b414.89d9.1883 DYNAMIC Gi0/18
 1 ecc8.8202.8282 DYNAMIC Gi0/15
 1 ecc8.8202.8283 DYNAMIC Gi0/16
 10 001a.2f55.c9e8 DYNAMIC Gi0/1
 10 001b.d40a.0538 DYNAMIC Gi0/2
Total Mac Addresses for this criterion: 29
Okay—know that your switch will show quite a few MAC addresses assigned to the 
CPU at the top of the output; those MAC addresses are used by the switch to manage the 
ports. The very first MAC address listed is the base MAC address of the switch and used 
by STP in the bridge ID. In the preceding output, we can see that there there are two MAC 
addresses associated with VLAN 10 and that it was dynamically learned. We can also 
establish that this MAC address is associated to Gi0/1. S1 looks really good!
Let’s take a look at S2 now. First, let’s confirm that port PC3 is connected and check its 
configuration. I’ll use the command show interfaces interface switchport command to 
do that:
S2#sh interfaces gi0/3 switchport
Name: Gi0/3
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 10 (Inactive)
Trunking Native Mode VLAN: 1 (default)
[output cut]
Okay—we can see that the port is enabled and that it’s set to dynamic desirable. This 
means that if it connects to another Cisco switch, it will desire to trunk on that link. But 
766 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
keep in mind that we’re using it as an access port, which is confirmed by the operational 
mode of static access. At the end of the output, the text shows Access Mode VLAN: 10 
(Inactive). This is not a good thing! Let’s examine S2’s CAM and see what we find out:
S2#sh mac address-table
 Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
 All 0100.0ccc.cccc STATIC CPU
 [output cut]
 1 001b.d40a.0538 DYNAMIC Gi0/13
 1 0021.1bee.a70d DYNAMIC Gi0/13
 1 b414.89d9.1884 DYNAMIC Gi0/17
 1 b414.89d9.1885 DYNAMIC Gi0/18
 1 ecc8.8202.8285 DYNAMIC Gi0/16
Total Mac Addresses for this criterion: 26
Referring back to Figure 18.5, we can see that the host is connected to Gi0/3. The problem 
here is that we don’t see a MAC address dynamically associated to Gi0/3 in the MAC address 
table. So what do we know so far that can help us? Well first, we can see that Gi0/3 is config￾ured into VLAN 10, but that VLAN is inactive. Second, the host off of Gi0/3 doesn’t appear 
in the CAM table. Now would be a good time to take a look at the VLAN database like this:
S2#sh vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/1, Gi0/2, Gi0/4, Gi0/5
 Gi0/6, Gi0/7, Gi0/8, Gi0/9
 Gi0/10, Gi0/11, Gi0/12, Gi0/13
 Gi0/14, Gi0/15, Gi0/16, Gi0/17
 Gi0/18, Gi0/19, Gi0/20, Gi0/21
 Gi0/22, Gi0/23, Gi0/24, Gi0/25
 Gi0/26, Gi0/27, Gi0/28
26 Automation10 active
27 VLAN0027 active
30 Engineering active
170 VLAN0170 active
[output cut]
Troubleshooting VLAN Connectivity 767
Look at that: there is no VLAN 10 in the database! Clearly the problem, but also an 
easy one to fix by simply creating the VLAN in the database:
S2#config t
S2(config)#vlan 10
S2(config-vlan)#name Sales
That’s all there is to it. Now let’s check the CAM again:
S2#sh mac address-table
 Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
 All 0100.0ccc.cccc STATIC CPU
[output cut]
 1 0021.1bee.a70d DYNAMIC Gi0/13
 10 001a.6c46.9b09 DYNAMIC Gi0/3
Total Mac Addresses for this criterion: 22
We’re good to go—the MAC address off of Gi0/3 shows in the MAC address table 
configured into VLAN 10.
That was pretty straightforward, but if the port had been assigned to the wrong VLAN, 
I would have used the switch access vlan command to correct the VLAN membership. 
Here’s an example of how to do that:
S2#config t
S2(config)#int gi0/3
S2(config-if)#switchport access vlan 10
S2(config-if)#do sh vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/1, Gi0/2, Gi0/4, Gi0/5
 Gi0/6, Gi0/7, Gi0/8, Gi0/9
 Gi0/10, Gi0/11, Gi0/12, Gi0/13
 Gi0/14, Gi0/15, Gi0/16, Gi0/17
 Gi0/18, Gi0/19, Gi0/20, Gi0/21
 Gi0/22, Gi0/23, Gi0/24, Gi0/25
 Gi0/26, Gi0/27, Gi0/28
10 Sales active Gi0/3
768 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
Okay, great—we can see that our port Gi0/3 is in the VLAN 10 membership. Now let’s 
try to ping from PC1 to PC3:
PC1#ping 192.168.10.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
No luck, so let’s see if PC1 can ping PC2:
PC1#ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
PC1#
That worked! I can ping a host that’s a member of the same VLAN connected to the same 
switch, but I can’t ping to a host on another switch that’s a member of the same VLAN, which 
is VLAN 10. To get to the bottom of this, let’s quickly summarize what we’ve learned so far: 
1. We know that the VLAN database is now correct on each switch.
2. The MAC address table shows the ARP entries for each host as well as a connection to 
each switch.
3. We’ve verified that our VLAN memberships are now correct on all the ports we’re using.
But since we still can’t ping to a host on another switch, we need to start checking out 
the connections between our switches.
Trunk Troubleshooting
You’ll need to troubleshoot trunk links when you lose connectivity between hosts that are 
in the same VLAN but are located on different switches. Cisco refers to this as “VLAN 
leaking.” Seems to me we are leaking VLAN 10 between switches somehow.
These are the steps we’ll take to troubleshoot VLANs:
1. Verify that the interface configuration is set to the correct trunk parameters.
2. Verify that the ports are configured correctly.
3. Verify the native VLAN on each switch.
And here are the commands we’ll use to perform trunk troubleshooting:
Show interfaces trunk
Show vlan
Troubleshooting VLAN Connectivity 769
Show interfaces interface trunk
Show interfaces interface switchport
Show dtp interface interface
switchport mode
switchport mode dynamic
switchport trunk native vlan vlan
Okay, let’s get started by checking ports Gi0/13 and Gi0/14 on each switch because 
these are what the figure is showing as forming the connection between our switches. We’ll 
start with the show interfaces trunk command:
S1>sh interfaces trunk
S2>sh interfaces trunk
Not a scrap of output—that’s definitely a bad sign! Let’s take another look at the show vlan
output on S1 and see what we can find out:
S1>sh vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/3, Gi0/4, Gi0/5, Gi0/6
 Gi0/7, Gi0/8, Gi0/9, Gi0/10
 Gi0/11, Gi0/12, Gi0/13, Gi0/14
 Gi0/15, Gi0/16, Gi0/17, Gi0/18
 Gi0/19, Gi0/20, Gi0/21, Gi0/22
 Gi0/23, Gi0/24, Gi0/25, Gi0/26
 Gi0/27, Gi0/28
10 Sales active Gi0/1, Gi0/2
20 Accounting active
[output cut]
Nothing new from when we checked it a few minutes ago, but look there under 
VLAN 1—we can see interfaces Gi/013 and Gi0/14. This means that our ports between 
switches are members of VLAN 1 and will pass only VLAN 1 frames! 
Typically I’ll tell my students that if you type the show vlan command, you’re really 
typing the nonexistent “show access ports” command since this output shows inter￾faces in access mode but doesn’t show the trunk interfaces. This means that our ports 
between switches are access ports instead of trunk ports, so they’ll pass information 
about only VLAN 1.
770 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
Let’s go back over to the S2 switch to verify and see which port interfaces Gi0/13 and 
Gi0/14 are members of:
S2>sh vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/1, Gi0/2, Gi0/4, Gi0/5
 Gi0/6, Gi0/7, Gi0/8, Gi0/9
 Gi0/10, Gi0/11, Gi0/12, Gi0/13
 Gi0/14, Gi0/15, Gi0/16, Gi0/17
 Gi0/18, Gi0/19, Gi0/20, Gi0/21
 Gi0/22, Gi0/23, Gi0/24, Gi0/25
 Gi0/26, Gi0/27, Gi0/28
10 Sales active Gi0/3
Again, as with S1, the links between switches are showing in the output of the show vlan
command, which means that they are not trunk ports. We can use the show interfaces 
interface switchport command to verify this as well:
S1#sho interfaces gi0/13 switchport
Name: Gi0/13
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
This output tells us that interface Gi0/13 is in dynamic auto mode. But its operational 
mode is static access, meaning it’s not a trunk port. We can look closer at its trunking 
capabilities with the show interfaces interface trunk command:
S1#sh interfaces gi0/1 trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 auto negotiate not-trunking 1
[output cut]
Sure enough—the port is not trunking, but we already knew that. Now we know it again. 
Notice that we can see that native VLAN is set to VLAN 1, which is the default native VLAN. 
This means that VLAN 1 is the default VLAN for untagged traffic.
Troubleshooting VLAN Connectivity 771
Now, before we check the native VLAN on S2 to verify that there isn’t a mismatch, I want 
to point out a key fact about trunking and how we would get these ports between switches to 
do that.
Many Cisco switches support the Cisco proprietary Dynamic Trunking Protocol 
(DTP), which is used to manage automatic trunk negotiation between switches. Cisco 
recommends that you don’t allow this and to configure your switch ports manually 
instead. I agree with them! 
Okay, with that in mind, let’s check out our switch port Gi0/13 on S1 and view its DTP 
status. I’ll use the show dtp interface interface command to view the DTP statistics:
S1#sh dtp interface gi0/13
DTP information for GigabitEthernet0/13:
 TOS/TAS/TNS: ACCESS/AUTO/ACCESS
 TOT/TAT/TNT: NATIVE/NEGOTIATE/NATIVE
 Neighbor address 1: 00211C910D8D
 Neighbor address 2: 000000000000
 Hello timer expiration (sec/state): 12/RUNNING
 Access timer expiration (sec/state): never/STOPPED
Did you notice that our port GI0/13 from S1 to S2 is an access port configured to auto￾negotiate using DTP? That’s interesting, and I want to delve a bit deeper into the different 
port configurations and how they affect trunking capabilities to clarify why.
Access Trunking is not allowed on a port set to access mode.
Auto Will trunk to neighbor switch only if the remote port is set to on or to desirable mode. 
This creates the trunk based on the DTP request from the neighboring switch.
Desirable This will trunk with all port modes except access. Ports set to dynamic desirable 
will communicate via DTP that the interface is attempting to become a trunk if the neighbor￾ing switch interface is able to become a trunk.
Nonegotiate No DTP frames are generated from the interface. Can only be used if the 
neighbor interface is manually set as trunk or access.
Trunk (on) Trunks with all switch port modes except access. Automatically enables trunk￾ing regardless of the state of the neighboring switch and regardless of any DTP requests.
Let’s check out the different options available on the S1 switch with the switchport mode 
dynamic command:
S1(config-if)#switchport mode ?
 access Set trunking mode to ACCESS unconditionally
 dot1q-tunnel set trunking mode to TUNNEL unconditionally
 dynamic Set trunking mode to dynamically negotiate access or trunk mode
 private-vlan Set private-vlan mode
 trunk Set trunking mode to TRUNK unconditionally
772 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
S1(config-if)#switchport mode dynamic ?
 auto Set trunking mode dynamic negotiation parameter to AUTO
 desirable Set trunking mode dynamic negotiation parameter to DESIRABLE
From interface mode, use the switch mode trunk command to turn trunking on. You 
can also use the switch mode dynamic command to set the port to auto or desirable trunk￾ing modes. To turn off DTP and any type of negotiation, use the switchport nonegotiate
command.
Let’s take a look at S2 and see if we can figure out why our two switches didn’t create 
a trunk:
S2#sh int gi0/13 switchport
Name: Gi0/13
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Okay—we can see that the port is in dynamic auto and that it’s operating as an access 
port. Let’s look into this further:
S2#sh dtp interface gi0/13
DTP information for GigabitEthernet0/3:
 DTP information for GigabitEthernet0/13:
 TOS/TAS/TNS: ACCESS/AUTO/ACCESS
 TOT/TAT/TNT: NATIVE/NEGOTIATE/NATIVE
 Neighbor address 1: 000000000000
 Neighbor address 2: 000000000000
 Hello timer expiration (sec/state): 17/RUNNING
 Access timer expiration (sec/state): never/STOPPED
Do you see the problem? Don’t be fooled—it’s not that they’re running in access mode; it’s 
because two ports in dynamic auto will not form a trunk! This is a really common problem to 
look for since most Cisco switches ship in dynamic auto. The other issue you need to be aware 
of, as well as check for, is the frame-tagging method. Some switches run 802.1q, some run 
both 802.1q and Inter-Switch Link (ISL) routing, so be sure the tagging method is compatible 
between all of your switches!
It’s time to fix our problem on the trunk ports between S1 and S2. All we need to do is to 
just fix one side of each link since dynamic auto will trunk with a port set to desirable or on: 
S2(config)#int gi0/13
S2(config-if)#switchport mode dynamic desirable
23:11:37:%LINEPROTO-5-UPDOWN:Line protocol on Interface GigabitEthernet0/13, 
changed state to down
Troubleshooting VLAN Connectivity 773
23:11:37:%LINEPROTO-5-UPDOWN:Line protocol on Interface Vlan1, changed state to 
down
23:11:40:%LINEPROTO-5-UPDOWN:Line protocol on Interface GigabitEthernet0/13, 
changed state to up
23:12:10:%LINEPROTO-5-UPDOWN:Line protocol on Interface Vlan1, changed state to up
S2(config-if)#do show int trunk
Port Mode Encapsulation Status Native vlan
Gi0/13 desirable n-isl trunking 1
[output cut]
Nice—it worked! With one side in Auto and the other now in Desirable, DTPs will be 
exchanged and they will trunk. Notice in the preceding output that the mode of S2’s Gi0/13 
link is desirable and that the switches actually negotiated ISL as a trunk encapsulation—
go figure! But don’t forget to notice the native VLAN. We’ll work on the frame-tagging 
method and native VLAN in a minute, but first, let’s configure our other link:
S2(config-if)#int gi0/14
S2(config-if)#switchport mode dynamic desirable
23:12:%LINEPROTO-5-UPDOWN:Line protocol on Interface GigabitEthernet0/14, changed 
state to down
23:12:%LINEPROTO-5-UPDOWN:Line protocol on Interface GigabitEthernet0/14, changed 
state to up
S2(config-if)#do show int trunk
Port Mode Encapsulation Status Native vlan
Gi0/13 desirable n-isl trunking 1
Gi0/14 desirable n-isl trunking 1
Port Vlans allowed on trunk
Gi0/13 1-4094
Gi0/14 1-4094
[output cut]
Great, we now have two trunked links between switches. But I’ve got to say, I really 
don’t like the ISL method of frame tagging since it can’t send untagged frames across the 
link. So let’s change our native VLAN from the default of 1 to 392. The number 392 just 
randomly sounded good at the moment. Here’s what I entered on S1:
S1(config-if)#switchport trunk native vlan 392
S1(config-if)#
23:17:40: Port is not 802.1Q trunk, no action
774 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
See what I mean? I tried to change the native VLAN and ISL basically responded with, 
“What’s a native VLAN?” Very annoying, so I’m going to take care of that now! 
S1(config-if)#int range gi0/13 - 14
S1(config-if-range)#switchport trunk encapsulation ?
 dot1q Interface uses only 802.1q trunking encapsulation when trunking
 isl Interface uses only ISL trunking encapsulation when trunking
 negotiate Device will negotiate trunking encapsulation with peer on
 interface
S1(config-if-range)#switchport trunk encapsulation dot1q
23:23:%LINEPROTO-5-UPDOWN:Line protocol on Interface GigabitEthernet0/13, changed 
state to down
23:23:%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, 
changed state to down
23:23:%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on 
GigabitEthernet0/13 (392), with S2 GigabitEthernet0/13 (1).
23:23:%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, 
changed state to up
23:23:%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/13, 
changed state to up
23:23:%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on 
GigabitEthernet0/13 (392), with S2 GigabitEthernet0/13 (1).
Okay, that’s more like it! As soon as I changed the encapsulation type on S1, DTP 
frames changed the frame-tagging method between S2 to 802.1q. Since I had already 
changed the native VLAN on port Gi0/13 on S1, the switch lets us know, via CDP, that 
we now have a native VLAN mismatch. Let’s proceed to deal with this by verifying our 
interfaces with the show interface trunk command:
S1#sh int trunk
Port Mode Encapsulation Status Native vlan
Gi0/13 auto 802.1q trunking 392
Gi0/14 auto 802.1q trunking 1
S2#sh int trunk
Port Mode Encapsulation Status Native vlan
Gi0/13 desirable n-802.1q trunking 1
Gi0/14 desirable n-802.1q trunking 1
Troubleshooting VLAN Connectivity 775
Now notice that both links are running 802.1q and that S1 is in auto mode and S2 is in 
desirable mode. And we can see a native VLAN mismatch on port Gi0/13. We can also see 
the mismatched native VLAN with the show interfaces interface switchport command 
by looking at both sides of the link like this:
S2#sh interfaces gi0/13 switchport
Name: Gi0/13
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
S1#sh int gi0/13 switchport
Name: Gi0/13
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 392 (Inactive)
So this has got to be bad, right? I mean really—are we sending any frames down that 
link or not? Let’s see if we solved our little problem of not being able to ping to hosts from 
S1 to S2 and find out:
PC1#ping 192.168.10.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Yes, it works! Not so bad after all. We’ve solved our problem, or at least most of it. Having 
a native VLAN mismatch only means you can’t send untagged frames down the link, which 
are essentially management frames like CDP, for example. So although it’s not the end of the 
world, it will prevent us from being able to remotely manage the switch, or even sending any 
other types of traffic down just that one VLAN.
776 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
So am I saying you can just leave this issue the way it is? Well, you could, but you 
won’t. No, you’ll fix it because if you don’t, CDP will send you a message every minute 
telling you that there’s a mismatch, which will drive you mad! So, this is how we’ll stop 
that from happening:
S2(config)#int gi0/13
S2(config-if)#switchport trunk native vlan 392
S2(config-if)#^Z
S2#sh int trunk
Port Mode Encapsulation Status Native vlan
Gi0/13 desirable n-802.1q trunking 392
Gi0/14 desirable n-802.1q trunking 1
[output cut]
All better! Both sides of the same link between switches are now using native VLAN 392 
on Gigabit Ethernet 0/13. I want you to know that it’s fine to have different native VLANs 
for each link if that’s what works best for you. Each network is different and you have to 
make choices between options that will end up meeting your particular business require￾ments the most optimal way.
Summary
This chapter covered troubleshooting techniques from basic to advanced. Although most 
chapters in this book cover troubleshooting, this chapter focused purely on IPv4, IPv6, and 
VLAN/trunk troubleshooting.
You learned how to troubleshoot step-by-step from a host to a remote device. Starting 
with IPv4, you learned the steps to test the host and the local connectivity and then how to 
troubleshoot remote connectivity. 
We then moved on to IPv6 and proceeded to troubleshoot using the same techniques 
that you learned with IPv4. It’s important that you can use the verification commands that 
I used in each step of this chapter.
Last, I covered VLAN and trunk troubleshooting and how to go step-by-step through a 
switched network using verification commands and narrowing down the problem.
Visit ccna 
.gg/ch18/b
for a 
companion 
MicroNugget 
from CBT 
Nuggets.
Exam Essentials 777
Exam Essentials
Remember the Cisco steps in troubleshooting an IPv4 and IPv6 network.
1. Check the cables to find out if there’s a faulty cable or interface in the mix and verify 
the interface’s statistics.
2. Make sure that devices are determining the correct path from the source to the destination. Manipulate the routing information if needed.
3. Verify that the default gateway is correct.
4. Verify that name resolution settings are correct.
5. Verify that there are no ACLs blocking traffic.
Remember the commands to verify and troubleshoot IPv4 and IPv6. You need to remember 
and practice the commands used in this chapter, especially ping and traceroute (tracert on 
Windows). But we also used the Windows commands ipconfig and route print and Cisco’s 
commands show ip int brief, show interface, and show route.
Remember how to verify an ARP cache with IPv6. The command show ipv6 neighbors
shows the IP-to-MAC-address resolution table on a Cisco router.
Remember to look at the statistics on a router and switch interface to determine problems.
You’ve got to be able to analyze interface statistics to find problems if they exist, and this 
includes speed and duplex settings, input queue drops, output queue drops, and input and 
output errors.
Understand what a native VLAN is and how to change it. A native VLAN works with 
only 802.1q trunks and allows untagged traffic to traverse the trunk link. This is VLAN 1 
by default on all Cisco switches, but it can be changed for security reasons with the 
switchport native vlan vlan command. 
778 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
Written Lab 4
The answers to this lab can be found in Appendix A, “Answers to Written Labs.”
Write the answers to the following questions:
1. If your IPv6 ARP cache shows an entry of INCMP, what does this mean?
2. You want traffic from VLAN 66 to traverse a trunked link untagged. Which command 
will you use?
3. What are the five modes you can set a switch port to?
4. You are having a network problem and have checked the cables to find out if there’s a 
faulty cable or interface in the mix and also verified the interface’s statistics, made sure 
that devices are determining the correct path from the source to the destination, and 
verified that you don’t need to manipulate the routing. What are your next trouble￾shooting steps?
5. You need to find out if the local IPv6 stack is working on a host. What command will 
you use?
Hands-on Labs for Troubleshooting
Please check www.lammle.com, www.lammlesim.com, and www.lammle.com/forum for the 
latest information and downloads available for studying when using my books. Precon￾figured hands-on troubleshooting labs are available for download, with the answers to 
the troubleshooting problems found on my forum. The troubleshooting hands-on lab 
simulator will be updated often.
Review Questions 779
Review Questions
The following questions are designed to test your understanding of this 
chapter’s material. For more information on how to get additional questions, 
please see this book’s introduction.
The answers to these questions can be found in Appendix B, “Answers to Chapter 
Review Questions.”

1. You need to verify the IPv6 ARP cache on a router and see that the state of an entry is 

REACH. What does REACH mean? 
A. The router is reaching out to get the address.
B. The entry is incomplete.
C. The entry has reached the end of life and will be discarded from the table.
D. A positive confirmation has been received by the neighbor and the path to it is 
functioning correctly. 
2. What is the most common cause of interface errors?
A. Speed mismatch
B. Duplex mismatch
C. Buffer overflows
D. Collisions between a dedicated switch port and an NIC
3. Which command will verify the DTP status on a switch interface?
A. sh dtp status
B. sh dtp status interface interface
C. sh interface interface dtp
D. sh dtp interface interface
4. What mode will not allow DTP frames generated from a switch port?
A. Nonegotiate
B. Trunk
C. Access
D. Auto
780 Chapter 18 u Troubleshooting IP, IPv6, and VLANs
5. The following output was generated by which command?
IPv6 Address Age Link-layer Addr State Interface
FE80::21A:6DFF:FE64:9B3 0 001a.6c46.9b09 DELAY Fa0/1
2001:DB8:3C4D:2:21A:6DFF:FE64:9B3 0 001a.6c46.9b09 REACH Fa0/1
A. show ip arp
B. show ipv6 arp
C. show ip neighbors
D. show ipv6 neighbors
6. Which of the following states tells you that an interface has not communicated within 
the neighbor-reachable time frame?
A. REACH
B. STALE
C. TIMEOUT
D. CLEARED
7. You receive a call from a user who says that they cannot log in to a remote server, 
which only runs IPv6. Based on the output, what could the problem be?
C:\Users\Todd Lammle>ipconfig
 Connection-specific DNS Suffix . : localdomain
 IPv6 Address. . . . . . . . . . . : 2001:db8:3c4d:3:ac3b:2ef:1823:8938
 Temporary IPv6 Address. . . . . . : 2001:db8:3c4d:3:2f33:44dd:211:1c3d
 Link-local IPv6 Address . . . . . : fe80::ac3b:2ef:1823:8938%11
 IPv4 Address. . . . . . . . . . . : 10.1.1.10
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 10.1.1.1
A. The global address is in the wrong subnet.
B. The IPv6 default gateway has not been configured or received from the router.
C. The link-local address has not been resolved, so the host cannot communicate to 
the router.
D. There are two IPv6 global addresses configured. One must be removed from the 
configuration.
Review Questions 781
8. Your host cannot reach remote networks. Based on the output, what is the problem?
C:\Users\Server1>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
 Connection-specific DNS Suffix . : localdomain
 Link-local IPv6 Address . . . . . : fe80::7723:76a2:e73c:2acb%11
 IPv4 Address. . . . . . . . . . . : 172.16.20.254
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 172.16.2.1
A. The link-local IPv6 address is wrong.
B. The IPv6 global address is missing.
C. There is no DNS server configuration.
D. The IPv4 default gateway address is misconfigured.
9. Which two commands will show you if you have a native VLAN mismatch?
A. show interface native vlan
B. show interface trunk
C. show interface interface switchport
D. show switchport interface
10. You connect two new Cisco 3560 switches together and expect them to use DTP and 
create a trunk. However, when you check statistics, you find that they are access ports 
and didn’t negotiate. Why didn’t DTP work on these Cisco switches?
A. The ports on each side of the link are set to auto trunking.
B. The ports on each side of the link are set to on.
C. The ports on each side of the link are set to dynamic.

D. The ports on each side of the link are set to desirable.

Comments

Popular posts from this blog

What if Analysis

What-If Analysis What-If Analysis in Excel allows you to try out different values (scenarios) for formulas. The following example helps you master what-if analysis quickly and easily.  Use scenarios to consider many different variables  A scenario is a set of values that Excel saves and can substitute automatically in cells on a worksheet. You can create and save different groups of values on a worksheet and then switch to any of these new scenarios to view different results. 
Create Different Scenarios 
Note: You can simply type in a different revenue and Cost into cell B2 and B3 respectively to see the corresponding result of a scenario in cell B4. However, what-if analysis enables you to easily compare the results of different scenarios.  
I. On the Data tab, click What-If Analysis and select Scenario Manager from the list. The Scenario Manager Dialog box appears  II. Add a scenario by clicking on Add.  III. Type a name (e.g. “First Case”), select cell B2 and B3 (represents “Revenue” and “…

PROFESSIONAL ENGLISH

Asking For and Giving Opinions on Likes and Dislikes

Words Meaning Sample Sentence Opinion A statement or judgment formed about some matter. Bhoomika gave her final opinion on the company’s matter. Dialogue A conversation between two or more people. Her dialogue stated her opinion about the company’s matter. Expression The action of making known one’s thought or feelings. Her expression was sad at the meeting. Frank An open, honest, and direct speech or writing Bhoomika is very frank with her friends. Recover Return to normal state of health, mind or strength. The company’s economic crisis will be recovered soon. Turmoil A state of great disturbance. The company is facing financial turmoil. Economics The branch of knowledge concerned with the production, consumption, and transfer of wealth. Bhoomika studied Economics at the State University. Betrayed Expose to danger by treacherously giving information to an enemy.

DAILY LIFE VOCABULARY

Apology Etiquette and Office Vocabulary 

Chapter Vocabulary

Word Meaning Sample Sentence Stressed A state of any mental or emotional tension. Ram seems much stressed after his poor exam. Launch An act of instance of starting something. The government launched a new scheme for the poor people. Error A mistake Ravi found a grammatical error in his new grammar book. Scold Blaming someone for any wrong doing Bhuvan scolded his employees for their poor performance. Accuse Claiming that someone has done something wrong. Bharati accuses her friend Chaya for stealing her necklace. Fair Good and honest Ravi got promoted for doing a fair job. Ashamed Embarrassed or guilty because of one’s action. <