It is Open Shortest Path First Version 3, or OSPFv3, for Internet Protocol version 6, or IPv6. When it comes to a multiarea OSPF implementation, if you know multiarea OSPF implementation for version 2 you know it for version 3. Area Border Routers, Autonomous System Boundary Routers, Dijkstra's algorithm, none of that has changed. They even keep the same LSA types. Type 1 and Type 2 - for Intra-area. Type 3 - Interarea. Type 5 - external routes.
The router ID for OSPFv2 was a 32-bit number, looked exactly like an IP address. Are we going to use a 128-bit number for OSPFv3? No! Not at all. We already explained that in the ICND1 class but once again - we're going to use a 32-bit number, just like we did before. Still looks like an IP version 4 address. When you configure OSPFv3 and you have no interfaces with IP version 4 addresses on it, what's the router ID we're going to be? The router is going to ask you for one and you need to set a router ID. Now here is something that is different? This is a big difference even though it's subtle. When we form adjacencies with IPv4 routing protocols, we start to communicate directly with IP addresses. On IPv6 it's going to be one of those link local addresses. And that's what we're going to communicate with. And this also means that we're independent of the subnet that is on the common link that disconnects us from that dependency that OSPFv2 has.
How do we recognize a link local address? It's FE80 – it's one of those self-assigned addresses that we get for ourselves. We use IPv6 for transport, no surprises there. It's enabled per link. We don't use network commands. We go to the interface level command, like we saw with OSPFv2, by the way. Now here's the cool part. So first how do we recognize multicast addresses in IPv6? In IPv6 they start with FF. What were the last two numbers that we saw for the Class D addresses that your OSPFv2 communicates with? 220.127.116.11 and then 18.104.22.168. That's what OSPFv2 uses, so .5 and .6. They kept the final numbers the same for us. How great is that! .9 for RIPng, .10 for EIGRP. So they really have tried to be as helpful as they possibly could with this transition for us.
As we mentioned above, we are specifying manually the router ID here. We don't have any interfaces running IPv4 in this topology. It is purely IPv6. So we have to specify with the router-id command in router OSPF configuration mode for IPv6.
Branch(config)#ipv6 router ospf 99
Branch(config-if)#ipv6 address 2001:DB8:D1A5:C900::1/64
Branch(config-if)#ipv6 ospf 99 area 0
HQ(config)#ipv6 router ospf 99
HQ(config-if)#ipv6 addr 2001:DB8:D1A5:C900::2/64
Branch(config-if)#ipv6 ospf 99 area 0
HQ(config)#interface Loopback 0
HQ(config-if)#ipv6 address 2001:DB8:AC10:100::64/64
Branch(config-if)#ipv6 ospf 99 area 1
Specified a process ID of 99, and that's what it is, a process ID that has not changed. Look down. Do you see a network command at all? No. We enable OSPF on interfaces at interface level for IPv6. And we do that with the ipv6 ospf process id command and then we specify the area we want this interface in. So in this case, Gigabit 0/1 is enabled for OSPF. It's in area 0 on branch. If we look at HQ, router ID manually set and Gigabit 0/1 is in area 0. With IPv6 OSPFv3 do we still have to be in the same area to form neighbor adjacencies? We do not because we remove ourselves from that dependency with that link local based communication. Focus your attention on the router–id command. We are manually setting our router ID here. There is no interface with an IPv4 address, so therefore it can't be automatically chosen in our topology. If there was an interface with an IPv4 address, fine it would be used. Same rules apply.
If there is a loopback interface with an IPv4 address, it's the highest loopback address that's used. If it says no loopback interface, then a physical interface would be used but only if they have IPv4 addresses. In this case, there is none. We manually set our router ID to all 1s on the branch and all 2s on HQ. But notice where we did that. We did that in router OSPF configuration mode. But it wasn't for IPv4 router OSPF configuration mode, it was IPv6 router OSPF configuration mode. And we still specify a process ID. It doesn't have to match.
So lot of similarities here. But notice every time we're dealing with IPv6, so OSPFv3, you're no longer using the ip command to start out, you're using ipv6 to start out. And remember that we don't have a network command here, no network commands for OSPFv3 or EIGRP for IPv6 or even for RIPng, okay?
Then we go to the interface level. That's where we enable OSPFv3. We have to specify ospf or ipv6 ospf 99 for the process ID area and that has to match. We're bound to the same area design rules. Now something that also strikes me is, I don't like inconsistencies. And the thing that bothered me when I configured EIGRP for IPv6 is, I had to do a no shutdown command on the routing process. We don't have to do that here. I almost wish that they would just keep it more consistent. But we don't have to do the no shutdown on the process here. But make sure that your areas are in the right place and there's really not a lot more to it.
Verifying OSPFv3 configuration
Let's verify which interfaces we've enabled OSPF on - show ipv6 ospf interface.
Branch#show ipv6 ospf interfaceEthernet0/1 is up, line protocol is upLink Local Address FE80::A8BB:CCFF:FE01:5510, Interface ID 4Area 0, Process ID 99, Instance ID 0, Router ID 22.214.171.124Network Type BROADCAST, Cost: 10Transmit Delay is 1 sec, State DR, Priority 1Designated Router (ID) 126.96.36.199, local address FE80::A8BB:CCFF:FE01:5510Backup Designated router (ID) 188.8.131.52, local address FE80::A8BB:CCFF:FE01:5610...Adjacent with neighbor 184.108.40.206 (Backup Designated Router)...
Some of the things to look for - the area that the interface belongs to, in this case area 0; process ID that was utilized, you can even verify the router ID here. But notice that all important link local address here. How do we know it's a link local address? Well it says local address, but it starts with what? FE80. So notice here, with OSPFv3, we are referring to our neighbors by that link local address. We're not referring to them by their global IPv6 address. So in this case, we're just looking at the designated router and backup designated router IP addresses but at their link local. And we can see who our adjacent is, whether it says 220.127.116.11. So that's referring to its router ID.
Remember how we told you that things don't really change that much? They don't change in regards to neighborship. We can see that we've got a full neighborship. Now we're on branch, right? So what is our status - DR or BDR, or other status? What do you think we are? So choose 3 - DR, BDR or druther.
Branch#show ipv6 ospf neighborOSPFv3 Router with ID (18.104.22.168) (Process ID 99)Neighbor ID Pri State Dead Time Interface ID Interface22.214.171.124 1 FULL/BDR 00:00:36 4 Gi0/1
Well, I can see here we've got the BDR, right? We got BDR showing in the output, so what is the branch router most likely? Well if our neighbor is the BDR, the backup designated router, there are only two routers on this multiaccess network, then branch would have to be the designated router. Because somebody has to be the designated router and it's definitely not HQ according to this output. So branch is DR. So if we're looking at the routing table, we can parse it for different sources and we can do that for IPv4 also. But we could do that for connected, local, static, we're here, OSPF, and we can see our route. Is this inside of our area?
Branch#show ipv6 routeIPv6 Routing Table - default - 4 entriesCodes: C - Connected, L - Local, S - Static, U - Per-user Static routeB - BGP, HA - Home Agent, MR - Mobile Router, R - RIPH - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interareaIS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMOND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - RedirectO - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISPOI 2001:DB8:AC10:100::64/128 [110/64]via FE80::A8BB:CCFF:FE01:5610, GigabitEthernet0/1...
It's an OI. But wait a minute, what's OI? It's "OSPF inter". So "inter" referring to "interarea". I'm thinking right now for Type 3 LSA. There you go. And that tells us it's outside of our area. Wonderful and we can compare that topology to branch. That's the network over there, past HQ. Looks good to me. We look at the beauty of the fact that they haven't changed administrative distance on us, not even the metric on us, 64. Okay. So what do we have here? We've got route to, in a network that is outside of our area. And notice that the prefix notation, /64, is the right convention. That's the right way to break up in terms of addressing. Chop your 128 bit address in half with that cleaver so that one side can be the subnet ID the other side can be your interface ID.
Take a look at the administrative distance folks for OSPFv3. Is it the same as OSPFv2? It is, no change there. Exactly the same - 110. Beside that, we see our cost via. With IPv4, via was referring to the next hop address, to get to that destination network. Is that what it is referring to here as well? It is. But there is a big difference here. What are we pointing to? Look at that address. It starts with FE80. It's the next hop address. What type of IPv6 address is that? Link local. So the next hop IP, address for OSPFv3 will always be a link local address, that of our neighboring router.
I think there's an elephant in the room after that discussion of OSPFv3. What's the prerequisite to doing that configuration that we saw? Something that I would expect to do first. Well, we have to turn on the ability to utilize IPv6 routing. Yeah, so we need IPv6 unicast routing turned on. Once we do that, we saw that difference for configuring the OSPFv3 process. Really, setting the router ID is the big difference. No network command, I think we can handle that. I love the network command, by the way, so I'll be sad when that's no longer part of my job role.
Now be confident with the verification. Let's say you had to troubleshoot this. You still got a lot of your same tools, show ip interface brief. Oh! just put in a v6. show ip protocols, just put on a v6 there. show ip ospf neighbor, just put on a v6 there. And then you're going to be able to troubleshoot anything to your heart's desire. So there's not a lot of difference with the troubleshooting. And I think that's great because I was like you folks, at least like the majority of you. I didn't want to have to learn a whole new protocol. IPv4 is big enough. IPv6, it'll eventually be bigger. But at least, they haven't changed everything on us.