Community discussions

MikroTik App
 
eduplant
Member Candidate
Member Candidate
Topic Author
Posts: 139
Joined: Tue Dec 19, 2017 9:45 am

OSPFv3 Type 9 LSA Behavior and Extra /128s

Sun Apr 03, 2022 9:53 am

I have been testing OSPFv3 on RouterOS v7.1.5 and run into what seems like a basic issue, but after scrutinizing the relevant section of RFC2740 [1], I can't quite puzzle it out. I'm hoping one of you with more OSPFv3 experience or someone from Mikrotik happens to see this and can comment.

From my understanding, one of the major changes between OSPFv3 and v2 is an attempt to separate out network prefix information from topology information. Whereas prefixes are indicated in the type-1 LSA in v2, in v3 they now appear in the new type-9 LSAs with a reference to the originating router ID (still found in type-1 LSAs).

In my basic two-router test, I attempt to advertise two stub prefixes per router to the neighboring router over a link with only IPv6 link-local addressing (no other associated prefix). A sketch of the simple topology is below with the prefixes color-coded to avoid your eyes glazing over from the nearly-identical hexadecimal :D. Exports of :ipv6 and :routing are attached, but they are essentially trivial. (For full disclosure, this link is actually a GRE tunnel, but that doesn't seem likely to have any relevance in this situation.)

r1_r2_ospfv3.png

When inspecting the link state database, each router includes all of the expected prefixes. In addition to the expected prefixes, however, each router chooses to include one of its own non-link-local interface addresses as a /128 with the LA bit set. Here is what this looks like, again color coded for easy comparison.

r1_ospfv3_lsadb_annotated.jpg

This is not just limited to the link-state database and the prefix is actually installed:

r1_ospfv3_route_dump.PNG

Referencing the section of the RFC pertaining to type-9 LSAs (section 3.4.3.7) [1], there seems to be some very specific and fiddly logic around when this should happen. The link between R1 and R2 is not a point-to-multipoint link or a loopback, but it is a point-to-point link without an assigned prefix. In this case, it would make sense for the router to proceed with selecting one of its available addresses, setting the LA bit, and including it as a /128.

In an attempt to avoid this, I assigned a prefix to the R1 to R2 link (fd00:0:2::/127). Unfortunately, the routers simply selected the new addresses on the R1 to R2 link and included that as a /128 to its neighbor:

r1_r2_ospfv3_lsadb_after.PNG

There is one more condition which involves virtual links, in which a similarly-selected /128 should be provided. There are no virtual links configured in the area.

So here are the takeaway questions:

1. Should RouterOS be unconditionally including these /128s in the database? My reading of the RFC implies that it is correct to do so for some circumstances but not all. It's very possible I'm missing some minutiae here.

2. If it is indeed supposed to do it in all circumstances or if Mikrotik deems it functionally harmless, is there at least a way we can control which address it picks? There doesn't appear to be an obvious pattern to which /128 it chooses, as it will hop around to any of the available non-link local addresses that is configured. Under most circumstances, /128s representing "loopback" bridges are usually already going to be in the database, whereas a selection of random /128s is less welcome and much harder to filter out in redistribution.

If it comes to adding a way to control it, I suggest adding :routing ospf interface-template type=loopback and prefer selecting the /128 from addresses configured on interfaces of that type first. I'm sure this would require significantly less pain and regression than introducing a native loopback interface type.

[1] https://datatracker.ietf.org/doc/html/r ... on-3.4.3.6
You do not have the required permissions to view the files attached to this post.
 
eduplant
Member Candidate
Member Candidate
Topic Author
Posts: 139
Joined: Tue Dec 19, 2017 9:45 am

Re: OSPFv3 Type 9 LSA Behavior and Extra /128s

Thu Apr 07, 2022 3:51 am

Bump.

I know scrutinizing the OSPFv3 database isn’t everyone’s idea of fun :D
 
aleksis
newbie
Posts: 25
Joined: Wed Apr 30, 2014 12:13 pm

Re: OSPFv3 Type 9 LSA Behavior and Extra /128s

Fri Apr 08, 2022 9:58 am

Those addresses are included for virtual links. Currently they are included unconditionally.
 
eduplant
Member Candidate
Member Candidate
Topic Author
Posts: 139
Joined: Tue Dec 19, 2017 9:45 am

Re: OSPFv3 Type 9 LSA Behavior and Extra /128s

Fri Apr 08, 2022 9:52 pm

Those addresses are included for virtual links. Currently they are included unconditionally.
Gotcha; that does appear to be one of the RFC circumstances in which they would be there. I'm still interested in whether or not Mikrotik is willing to give us a way to pick an address off of a loopback rather than there just being arbitrary /128s in the table that I have to filter out when redistributing.

Who is online

Users browsing this forum: No registered users and 16 guests