I'm not really sure if this is going to teach us anything except the fact that they really tried to make EIGRP seamless for us. It is straightforward albeit different to configure, still rooted in the DUAL algorithm, making it advanced, and ever since its inception, EIGRP tried to sport more than just IP before it did Apple Talk, it did IPX. And now, very similarly to how multiprotocol Border Gateway Protocol, or BGP, works with, its independence of different routing protocols, EIGRP works the same way. It is configured however not inside of the Internet Protocol version 4, or IPv4, routing process. We have to go into a different routing mode to configure this beast.
There's only one aspect here that is different from what we've discussed for IP version 4. Which one is it? Well IP version 4, we formed neighbor discoveries, we formed neighborships and command pool updates, we used DUAL, we already know that. But it's that fourth point that is different. What multicast address did we utilize for EIGRP for IP version 4, 188.8.131.52. Are we using that here? No. Because it's no longer IP version 4, it's IP version 6. So the multicast starts off with FF and remember that like link local is FE80. So it's not link local, FF multicast 02 :: A, or FF02::A. I think to myself, what is that letter A? Oh it's hexadecimal. What does A translate to? Let's think about that. We have 0 through 9 for hex and then, we go A, B, C, D, E, and F. A is the first. I say it's 10. It's definitely 10. But wait a minute, that's the same as the 10 of EIGRP's multicast for IPv4. This is different stuff that precedes it, which is still just an indication of a non-routed multicast address. All right. So as we said, it's the only thing that's different here. If we continue on, composite metric, load balancing, three tables, yes, everything is good, folks. It's all the same.
EIGRP for IPv6 configuration example
Where we really see the major difference is in regards to the configuration. And there's some little, little things that we really have to be aware of when it comes to EIGRP for IP version 6 that, you know, if we don't do that one specific thing, it's not going to work as we intend it to work. So first and foremost - is IP version 6 routing turned on by default? No. I still haven't touched a Cisco Chassis where routing for v6 is turned on and I want you to know what turns it on for v4. It's the "ip routing" command in global config. That's for v4. So we got to turn it on. We now know that we got to turn it on for v6 and we see how to do that on the top line and that really needs to be something you understand as a requirement.
Branch(config)#ipv6 unicast-routingBranch(config)#ipv6 router eigrp 100Branch(config-rtr)#no shutdownBranch(config-rtr)#exitBranch(config)#interface GigabitEthernet0/1Branch(config-if)#ipv6 eigrp 100
When we say, this is required before something else, that also tells me, I probably want to know that for examination purposes. So you do ipv6 unicast-routing, get that, and that flips the switch. Hey! It enables all the v6 routing protocols, OSPFv3, RIPng, but we're talking about EIGRP. So how do we set up EIGRP for v6?
Well we're going to go to two different places on our router to set up EIGRP for IPv6. The first place we're going to visit is, router EIGRP configuration mode for IPv6. And we see how we get there with the ipv6 router eigrp command. Specifying autonomous system number, so really nothing different with this command except for that IPv6 at the beginning. That autonomous system number still has to match. If it doesn't match, you won't form neighbor adjacencies. But now, notice the command. It says no shutdown.
So that's a convention that we got back from like the 1980s, that was relegated to just the interfaces. Cisco is changing its strategy with protocols in different compartmentalized aspects of the chassis like protocols, and so they want to see more of this kind of functionality where you can shut no shut aspects of the functionality and that's what's going on here. Very confusing.
So we used this no shutdown command to enable the EIGRP autonomous system 100 process on this particular router. Now do I use the network command with IPv6 EIGRP? No and I'm still a sucker for the network command. I like it, but we throw away the network command for EIGRP, OSPF, and even RIP. Instead, we go to the new paradigm. The new paradigm is directly turning it on and off on a per interface basis and we do that under interface configuration. But we saw hints of this with OSPF, if you can remember that far ago, that long ago, but this is the right process, right procedure.
So we're on branch right now. We go to GigabitEthernet0/1 and we use the command ipv6 eigrp 100 and that turns on EIGRP on that specific interface for autonomous system 100. So be careful. Do not get the autonomous system number wrong anywhere in your configuration. If you accidentally typed in 10 there, sorry, autonomous system 10 is not running on this router, 100 is. So you have to get that right. But it would let you enter that by the way, because you can have multiple autonomous systems for EIGRP running.
Let's look at HQ now. Anything different there? No. Let's turn on IP version 6 routing. How do we do that? Very top command, ipv6 unicast-routing. Don't forget that. How do we enable the EIGRP process on this particular router? Well same command, really. ipv6 router eigrp 100, do a no shut, then fall back to the interfaces, one by one, do that command, ipv6 eigrp 100.
HQ(config)#ipv6 router eigrp 100
HQ(config-if)#ipv6 eigrp 100
HQ(config-if)#ipv6 eigrp 100
The thing I really like about verification for IPv6 is that the commands are very, very similar to IPv4, as well as their output, with one slight modification. Instead of typing in ip, you type in ipv6.
The majority of the output here is the exact same as IPv4, but something is jumping out to me right now that is significantly different from IPv4 and that happens to be this link local address information. So pull from your knowledge of IPv6 for a moment, folks. Link local is a self-assigned IP address, self-assigned and it's non-routable, which is what link local says. But when we look at v6 protocols such as EIGRP and OSPF for IPv6, when they see that they really fall back and like to use this, they like to use the link local addresses for communication. So even though there may be a global address and we can see the global address in the topology, we don't use it. Here is why. The routing protocol wants to be independent of those global addresses. It wants to make it so that if we wanted to even readdress that link between it with different global addresses or additional global addresses that we wouldn't care, which is a really cool stuff. And knowledge that your dynamic routing protocols for v6 use link local addresses will help you troubleshoot. It really will. So anytime you see a v6 address that begins with FE80, that means it is a link local address.