ospf6 does not add routing rules if subnet differs on link

[sredman]

Hello,
I can't tell if this situation is the result of a bug or the result of a unsupported configuration

I have a network running in a testbed of x86 nodes, all running FRR, which looks like this:

| N1 <---> OVS <---> N2 <---> N3 |

The OVS is configured as a passthrough (not running FRR), so is probably irrelevant for this discussion, but I have shown it anyway in case it has some relevance

All nodes believe they belong to /64 IPv6 subnets

Node 1 has IPv6 address fd00:10:10:6:204:23ff:feb7:22a4
Node 2 has IPv6 address fd00:10:10:4:204:23ff:feb7:18eb on the interface facing Node 1, and fd00:10:10:2:204:23ff:feb7:18ea on the interface facing Node 3
Node 3 has IPv6 address fd00:10:10:2:204:23ff:feb7:15fd

The thing to notice about the connection between Node 1 and Node 2 is that the subnet on one end of the link is different from the subnet on the other end. The OVS does no translation, just passes the traffic along.

Everything functions as I had hoped on Node 1 and Node 3. OSPF eventually picks up a route for one to communicate with the other via Node 2. However, Node 2 does not populate its own routing table with a route to fd00:10:10:6::/64, even though it advertises one to Node 3! (If I add nodes past Node 3, Node 2 does correctly add those to its routing table)

For instance, if I try to use ping6 from Node3 to Node1, I get the error:
ping6 fd00:10:10:6:204:23ff:feb7:22a4 -c 1 PING fd00:10:10:6:204:23ff:feb7:22a4(fd00:10:10:6:204:23ff:feb7:22a4) 56 data bytes From fd00:10:10:2:204:23ff:feb7:18ea icmp_seq=1 Destination unreachable: No route
(Ping from Node1 to Node3 dies silently, since Node2 is able to route the packet to Node3 but the reply can't be routed back)

If I restart frr on Node 2 (systemctl restart frr), it adds the correct routing rules, and I am able to ping, etc. from Node 1 to Node 3

Node 2 is running the latest prebuilt Ubuntu release version of FRR (version 5.0.1). Nodes 1 and 3 are running version 4.0 (I can update if desired)

The only FRR daemons I have running are zebra and ospf6d (see attached config files)

Note for the attached files: The physical topology actually has more nodes past Node 3, but I have turned off (physically powered down) the next node in the chain to test just this configuration, thus why there are references to a fd00:10:10:1::/64 subnet

The flow table in the OVS looks like:

sudo ovs-ofctl dump-flows br0 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=6116.985s, table=0, n_packets=676, n_bytes=66860, idle_age=9, priority=0,ipv6,in_port=2 actions=output:1 cookie=0x0, duration=6116.985s, table=0, n_packets=668, n_bytes=64676, idle_age=9, priority=0,ipv6,in_port=1 actions=output:2
(In other words, straight passthrough)

ospf6d-node2.log
zebra-node2.log
zebra-node1.log
ospf6d-node1.log
zebra-node3.conf.txt
ospf6d-node3.conf.txt
ospf6d-node2.conf.txt
zebra-node2.conf.txt
ospf6d-node1.conf.txt
zebra-node1.conf.txt
ipv6_routes-node3.txt
ipv6_routes-node2.txt
ipv6_routes-node1.txt

[bisdhdh]

This should be a BUG in ospfv3. As per OSPFv3 RFC says that two routers can share OSPFv3 packets over a link with multiple defined subnets, even if the two routers are not on the same subnet.

[Jafaral]

In the current code there is no directly connected subnet check for neighborship to bring up.

@bisdhdh can you please enable adjacency logging ?
under router ospf6:

 log-adjacency-changes detail

Please provide the output of the following commands:

show ipv6 ospf6 neighbor detail
show ipv6 ospf6 interface
show ipv6 ospf6 interface traffic
show ipv6 ospf6 database  

Thanks!

[sredman]

@Jafaral I'm not sure if you meant to tag me, but I have made the change to the config file and attached the command outputs

I have updated all of the nodes to Ubuntu 18.04/FRR v5.0.1 to see if that helped. I don't see any difference.

Does log-adjacency-changes detail only work on FRR v4? It is giving me 2018/08/14 11:32:49 OSPF6: ERROR: No such command on config line 12: log-adjaceny-changes detail on v5.0.1

The only structural change from my original post is that there are no nodes past node3 any more, so you don't see that interface configured on node 3. The router-ids have changed but the hostnames are the same. If you would like to see the latest config files I can grab those but they are basically the same!

outputs-node1.txt
outputs-node2.txt
outputs-node3.txt

[Jafaral]

Thanks @sredman! working on it

[Jafaral]

@sredman,
The "log-adjaceny-changes detail" command is under router ospf6

Can you also run:

show ipv6 ospf6 route detail

and validate the installed route and its nexthops

[sredman]

Routes and nexthops look good on N1 and N3, including the prefix change boundary for N1

For N2 it has an entry for the other prefix at the prefix change, but nothing is listed under the Nexthop section (literally just a blank line). As might have been expected, the entries for the other two prefixes are normal

I think I don't understand what you mean by "under router ospf6". Does it go in the config file? In which case, what have I done wrong in the attached? (Note that my prefixes have actually changed for the same reason as above. I have now reserved the nodes in my experiment for a bit so we can keep debugging without things changing)
ospf6d-node2.conf.txt

[Jafaral]

one more thing to look at is:

show ipv6 ospf6 spf-tree

[sredman]

The closest command I could find to what you requested is show ipv6 ospf6 spf tree (with no dash). I don't know what that result should look like, so I won't try to interpret the results. The only thing I added is a "translated" section where I converted the router IDs to their names as in the first post. Let me know if this is too confusing!
node3 spf-tree.txt
node1 spf-tree.txt
node2 spf-tree.txt