We're not going to see a lot of new troubleshooting, when we really get into IPv6. But we're going to explore end-to-end connectivity and we might see a few new things along the way.
We're under a new lesson, a new discussion on IPv6 but boy, this looks like what we saw for IPv4. It's the exact same. There's no difference here. We mentioned earlier that if we knew how to troubleshoot IP version 4, we can take everything we learned from IP version 4 troubleshooting and bring it with us over to IP version 6, including a flow. A flow of steps that you could take. But we don't want to get lost in the flow, folks, just like with IP version 4. Let's not get lost in the flow. But we're going to go through this flow. We're going to look at the different steps and techniques we can utilize, and again the majority of them, we already know.
So, let's start off with end-to-end connectivity. But before we dive in, just off the top of your head with IP version 4, when we were troubleshooting end-to-end connectivity what were the commands we utilized?
Ping and traceroute. Alright, no surprise here. Ping and traceroute. Notice that we can shorten addresses with the ping utility and we don't even have to tell Windows or a router that we're pinging an Internet Protocol version 6, or IPv6 address. Both operating systems are intelligent enough to know, hey, that doesn't look like IPv4.
So you see the shortened address with that :: to fill the space for many zeros bounded by those colons, which I call quartets, dropping off leading zeros so we can do that. We can also do a traceroute and the interpretation of these outputs really the same as what we would interpret from IPv4 versions of these same utilities.
No surprise here, ping and traceroute. Use them on our routers, use them on our switches, of the ability there as well. So just remember you want to test connectivity, all of our IPv6 enabled devices will give us the ability.
We still have telnet and we can still do that port test, right? Remember how we could overwrite the default port of telnet and if we get that open, it indicates that, that service is on. It might not be expecting telnet to come in through that service but that service is on. And so we see that done here.
C:\Windows\system32\telnet 2001:DB8:172:16::100 80
HTTP/1.1 400 Bad Request
400 Bad Request
Connectin to host lost.
So this is an interesting way of testing. Let's say access control lists, or ACLs wanted to make sure that port 80 was allowed through all the ACLs in the path of connectivity.
Now, this is new. I don't recall seeing this with IP version 4. What are we looking at here?
Branch#show ipv6 neighborsIPv6 Address Age Link-layer Addr State InterfaceFE80::21E:7AFF:FE79:7A81 8 001e.7a79.7a81 STALE Gi0/12001:DB8:101:1:A083:AEE4:E7C5:2CCA 46 000c.2936.fdf7 STALE Gi0/02001:DB8:209:165::2 0 001e.7a79.7a81 REACH Gi0/12001:DB8:101:1:C31:CD87:7505:F9FB 0 000c.2952.51fd REACH Gi0/0
With IP version 4, what do we utilize to discover the layer 2 address of a known layer 3 address? So in other words, what do I use to determine the MAC address of an IP address I already know about? It's ARP, ARP - Address Resolution Protocol. Do we have ARP with IP version 6?
No, and that really will be one of things that you might struggle with when you are trying to learn IPv6, no joke. So the new deal, the new ARP is Internet Control Message Protocol, or ICMP. It's a version or a subfunction of ICMP called Neighbor Discovery, okay. Neighbor Discovery takes on the exact same function, does the exact same thing. Now we can't broadcast an IPv6. So ICMP will instead have to do a multicast to all hosts in the subnet but the same basic idea applies. So that's a real thing that we want you to internalize. No ARP. ICMP neighbor discovery, instead. And so, what we are viewing here is the output of the ICMP neighbor discovery. So that netsh interface IPv6 show neighbor. Oh, wow! Glad, I don't have to do that too often in a command prompt on a Windows PC.
C:\Windows\system32>netsh interface ipv6 show neighborInterface 14: Wireless Network ConnectionInternet Address Physical Address Type-------------------------------------------- ----------------- -----------fe80::9c5a:e957:a865:bde9 00-0c-29-36-fd-f7 Stalefe80::fa66:feff:fe31:7250 f8-66-f2-31-72-50 Reachable (Router)ff02::1 33-33-00-00-00-01 Permanentff02::2 33-33-00-00-00-02 Permanentff02::c 33-33-00-00-00-0c Permanentff02::16 33-33-00-00-00-16 Permanentff02::1:2 33-33-00-01-00-02 Permanentff02::1:3 33-33-00-01-00-03 Permanentff02::1:ff20:4696 33-33-ff-20-46-96 Permanent
But it's pretty cool output because we can see. Hey, not only the IPv6 address and the MAC address, and looks like it's a FE80 address, so that's link local. We can also see using EUI-64 because it's got FF, FE in the middle. It's usually what we're going to see for link local
We can also see that this is a router. That's really good output. That's better than the output that we got from the ARP -A command. So I think it's cool. It looks like we can do something similar but a lot easier on a Cisco router. Definitely, I like this command much more and that is the show IPv6 neighbors command that will display the IPv6 address to our MAC address mappings for IPv6. And we can see on our router down here that link local address of FE80 as well and the MAC address associated with that. Some very, very powerful commands to troubleshoot our layer 3 to layer 2 resolution. Remember it's not ARP for IP version 6, it's ICMP with Neighbor Discovery.