OSPFv3

This post builds on the previous one, talking about IPv6.

Router-id
If we don’t configure one, OSPFv3 will choose a Router ID in the same fashion as OSPFv2.

After configuring basic OSPFv3, I see the following:

If we remember with OSPFv2 over NBMA networks, we must ensure that broadcasts are forwarded properly on interfaces. We generally use the “broadcast” keyword in “frame-relay map ip..” command.
Here, I added the static mapping command, with the “broadcast” keyword:

But it was not enough. I still do not see neighborship established. Something was missing:

What if it was a mismatched OSPF network type on both ends of the link?
Bingo.
Now neighbors stand up!

What if we delete the “frame-relay map ipv6..” command? Neighbor state goes “init”:

OSPF Database
Intra area Prefix Link State is LSA9.
Inter area Prefix Link State is LSA3
R3 OSPF database:
On R1 and R4 e.g., we see OSPF routes:
R4 sees all routes (not a default route only).

OSPF neighborship does not form
Let’s “debug ipv6 ospf hello”. From the following, we know that OSPFv3 uses link local addresses in its conversations, and that we have here mismatched Hello parameters. We know that, in order for OSPF neighborship to establish, these parameters must match (in the Hello packet):
– area ID
– authentication
– Hello timer, Dead timer
– stub area flag.
So if for example routers have different OSPF network types, that mean they have different values in one of the aforementioned parameters.

to solve it:

Sometimes, commands such as “debug ipv6 ospf hello” and “debug ipv6 ospf event” are not enough. Try “debug ipv6 packet” because the problem may be due to packet processing itself:
The “encapsulation failed” message on NBMA network can be solved with “frame-relay map ipv6..broadcast” command, like this:
“frame-relay map ipv6 {remoteLinkLocal here} {DLCI here} broadcast”

OSPFv3 configuration for TSHOOT lab, on R1

OSPF configuration for TSHOOT lab, on R2:

Route summarization
Beware not to do the conversion from decimal to binary! ipv6 addresses are in hex! so we should convert from hex to binary.

– if you configure OSPFv3 and there’s no IP address on router, then IOS will ask you to set Router-ID manually:

Redistributing connected routes into OSPFv3
we delete loopbacks from being advertized as OSPF internal routes (on R1) and we’ll redistribute their addresses into OSPF:

We chose 300 because it is greater than any internal route metric.
Let’s see R2 routing table:

Routes are learned as O E2, just like OSPFv2 :)

Redistributing RIPng into OSPFv3
Quite simple, if we already know redistribution in IPv4. By the way, knowledge is always useful. We either use it exactly as it is, or we do analogies between what we know and what we’re about to learn.

Let’s see what R3 has learned:

Where is the 2026::2:/122 network? it is supposed to be a RIPng route, so it should be redistributed.
I found the answer to it with “include-connected” keyword:

The redistributed RIP routes appear now on R3 routing table:

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *

*