ICND1 100-105

ICND1 100-105

Configuring OSPFv3

We've already hinted at this. Open Shortest Path First, or OSPF, for Internet Protocol version 6, or IPv6 is v3 whereas the earlier version we saw, v2, was the link-state routing protocol for Internet Protocol version 4, or IPv4. Is there are a lot different? No. We want to talk about Routing Information Protocol Next Generation, or RIPng, but there's not a lot different between RIPng and RIPv2. They really try to preserve everything that they can and we thank the designers for that wholeheartedly. Still have a router ID, and how close is it to the router ID of the OSPFv2? It is the same. Isn't that funky. It really is a 32-bit value. You couldn't chuck in a 128-bit value. Do you remember the phrase that pays for router ID selection? Now that we mentioned it, what was it?

Higher is better, but loopback wins. So we will need an IPv4 address on our OSPF router somewhere if we are running OSPF version 3, simply for the purpose of a router ID, so either use the router ID command or set up a loopback interface that will be used specifically for this purpose. We communicate via link-local addresses, at least that's what we use as our source, and then when we find who we want to talk to, when we know the router we want to communicate with, we'll still use it's link-local address. We already mentioned link-state advertisements, and they are communicated with IPv6, so we don't still use v4. That would be problematic because we may not have a v4 network to piggyback on. I want to remind you of something. We indicated the dependency of being in the same subnet for OSPFv2. We do not have that anymore. We do not need to be in the same subnet. It's not good, therefore, not in the same subnet, but we lack that dependency now, and we enable it per link, which means per subnet. Anytime you are going through IPv6 document and they say link, substitute subnet, that'll help you, okay, that'll help you. So in this case, major things are mostly the same on v3.

IPv6 OSPFv3 Configuration

Configuration though, is different. OSPF version 2. Where did we go to identify which interfaces would be enabled for OSPF? Recall that. I vividly remember spending time in router configuration mode for OSPF and using, which command was that? It was the network command. The network command identified, which interfaces would be enabled for OSPF. Look very closely here.

Branch(config)#interface GigabitEthernet0/0
Branch(config-if)#ipv6 ospf 1 area 0
Branch(config)#interface GigabitEthernet0/1
Branch(config-if)#ipv6 ospf 1 area 0
Branch(config)#ipv6 router ospf 1

HQ(config)#interface GigabitEthernet0/0
HQ(config-if)#ipv6 ospf 1 area 0
HQ(config)#interface GigabitEthernet0/1
HQ(config-if)#ipv6 ospf 1 area 0
HQ(config)#ipv6 router ospf 1

Do you see any network command? I don't. I don't see it at all. So where are we configuring OSPFv3? How do we turn it on? Interfaces! We go to interface configuration mode. On branch, in HQ, we go to those specific interfaces and we type in ipv6 ospf, and then specify the process ID, and the area we want this interface to belong to. It's that easy. No need to worry about messing up network statements here. No. Just go to the interface, and turn it on, turn it on. It's a great command. We still have a router configuration mode though, for OSPFv3. Why? For those parameters that would affect the entire router when it comes to OSPF. For example, the router ID. Do you want to configure a router ID? You go into router OSPF configuration mode for that particular process, process 1, and you specify the router ID command, and notice it's a 32-bit value and IP address doesn't have to be any type of valid IP address at all. No. Just a 32-bit number to represent the device. So, this really is a much simpler configuration than what we had with version 2, isn't it?

It is and what's interesting and you can specify OSPFv2 in a very similar manner. The syntax is roughly the same. You just drop off the v6. However, that's not what you're responsible for. That's why we didn't teach it to you there. But like we said, there is no network command, and there isn't a network command for any of the dynamic routing protocols with the exception of Border Gateway Protocol, or BGP, and BGP uses the network command fundamentally differently than all of the rest. But this is great. So think about it holistically now. You've got up/up interfaces. We then put IPv6 addresses everywhere we need them, maybe we use some stateless auto configuration. We build routing. We should be able to ping all IP addresses from any properly addressed IPv6 host now that we've done this.

OSPFv3 verification commands

So let's go to the branch router's routing table for IPv6, and let's verify if we have an OSPF entry for that network on the other side of HQ. If everything is configured properly, we should get down to the routing table here for OSPF.

Branch#show ipv6 route ospf
IPv6 Routing Table - default - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
       ND - Neighbor Discovery
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
O   2001:DB8:AC10:100::64/128 [110/1]
     via FE80::A8BB:CCFF:FE00:3410, GigabitEthernet0/1

I see an entry here. I see an O entry, which means it's a network inside of our area. We can see the administrative distance. Oh, it's the same, isn't it, as OSPF version 2? No different.

Let's quiz you right now. What are your administrative distances? We saw it a really long time ago, okay. Connected routes 0, static routes 1, Enhanced Interior Gateway Routing Protocol, or EIGRP 90, OSPF 110, RIP 120. Do you know all of them? You should. You need to, okay. 110, same. That's how cool it is of Cisco to try to preserve all that we've learnt and repurpose it for a whole new protocol suite. So they're doing us a solid and we should thank them for that and what's the number that follows the slash. We have to be able to read this information in brackets regardless of its v4 route or v6 route. What's that /1? Can you tell us? Can you tell us? What is it?

That's our metric. It's cost. How far away that destination network is away from us.

And then, we just have the next hop and the exit interface.

Look at something though, about that next hop folks. What is that? Is that a global address? No, no, no, no. OSPF version 3 uses that link-local address that we defined for you so well. OSPF will form its neighborships using these link-local addresses as well. So it's always, always going to use that in the routing table as the next hop IP addresses. Because, well where is that next hop? Let's hope my local interface with my link-local address and link-local address on the other end of that link should be part of the same, should be part of that same local subnet we're in. What interface do I use? Gigabit Ethernet 0/1.

No surprise here. We want to verify our neighborships, show ipv6 ospf neighbor.

Branch#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface 1 FULL/BDR 00:00:36 3 GigabitEthernet0/1

There is really nothing different here in regards to the output from IP version 4, is there?

Not a thing. Not one thing, at least of significance, okay. We see the router ID, we see the priority, we see the state, we didn't really talk about states in our OSPFv2 discussion. But full means, we have a full adjacency, we're happy. We mentioned the designated router, or DR, and the backup designated router, or BDR. We still have these concepts when we're working on Ethernet, and that in fact tells us that the other side is the BDR. So we are the DR, by process of elimination because we need the DR, dead time interface, okay. But if we're troubleshooting this, we see full, boom! We see the number of rows, we see full and then we move on to the next thing because this is happy and satisfying output.

To verify your router ID with OSPF version 3, show ipv6 ospf. That's just our general, general OSPF verification command. It will provide us with a lot of information you can see here.

Branch#show ipv6 ospf
 Routing Process "ospfv3 1" with ID
 Event-log enabled, Maximum number of events: 1000, Mode: cyclic
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Graceful restart helper support enabled
 Reference bandwidth unit is 100 mbps
< output omitted >

But the most important thing, that we really want to make note of, is one, that process ID. The process ID we're running here with OSPF. What is our router ID? Number 2. But, as we start filtering through the output with the SPF timers, the shortest path first timers and pacings and so on, no, we're in the weeds. We're in the weeds. It's not our concern. But what I would like to verify is down at the bottom. There is some good information there at the bottom in regards to our areas as well as that reference bandwidth.

We saw this for OSPFv2. Remember, we saw a little bit about stub and not so stubby areas, you don't have to know that stuff, okay. But we saw it online. This says the number of areas on the router, the number as 1. The area numeric value, however, is 0. So we're plugged into one area, which is numbered 0, which is still the backbone area. We see the reference bandwidth also and we had a hint at the reference bandwidth just a second ago. We saw when we looked at the v6 routing table, learnt by OSPF, we saw administrative distance of 110, and then we saw cost of 1, and that was out of gigabit interface. So we know that the reference bandwidth was somewhere between 100 and 1000. We know it's not less than 100, because that would be madness, okay. But they kept it here as 100 on our Cisco router chassis. Now Cisco, again, does have other defaults depending on the kind of chassis you're working with. If you find yourself working on Data Center gear, validate the reference bandwidth there. I say that because you may have an environment that has Cisco Nexus devices and Cisco routers and multilayer switches of the Catalyst variety, you would want to align the reference bandwidth between all of them.