Routed v6 prefix not announced via OSPF

[laxxie]

• FRR VERSION: 9.0.1 (from Repo)

• OPERATING SYSTEM VERSION: Ubuntu 22.04

• KERNEL VERSION: 6.2.0-33-generic x86_64

• [x ] Did you check if this is a duplicate issue?

• Did you test it on the latest FRRouting/frr master branch?

We have a problem with routed v6 prefixes. If we route a v6 prefix to another v6 address the prefix is not announced via OSPF.
In example: 2a00:TTT:XXX::/126 is routed to 2a00:TTT:YYY::2 on our edge router

With FRR 8.5.3 we can see the prefix via OSPF on our core router:

> show route 2a00:TTT:XXX::

inet6.0: 189365 destinations, 422184 routes (189319 active, 1 holddown, 77 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

2a00:TTT:XXX::/126
                   *[OSPF3/150] 00:00:40, metric 20, tag 0
                    >  to fe80::a236:... via xe-0/1/0.ABC
                       to fe80::a236:... via xe-0/1/4.CBA
>

With FRR 9.0.1 the prefix is not exported via OSPF

> show route 2a00:TTT:XXX::

inet6.0: 189366 destinations, 422165 routes (189319 active, 2 holddown, 77 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

2a00:TTT::/32     *[Static/5] 5w2d 10:28:54, tag
                       Discard
>

We don't see anything in the logs and no errors occuring.

FRR Config

ipv6 route 2a00:TTT:XXX::/126 2a00:TTT:YYY::2

interface enp8s0f1.ABC
 ip ospf network point-to-point
 ipv6 ospf6 area 0.0.0.0
 ipv6 ospf6 network point-to-point
exit

router ospf6
 redistribute connected route-map redist-ospf-ipv6
 redistribute static route-map redist-ospf-ipv6

ipv6 prefix-list allowed-ospf-vlan233 seq 5 permit 2a00:TTT:YYY::/126
ipv6 prefix-list allowed-ospf-vlan233 seq 10 permit 2a00:TTT:XXX::/126

route-map redist-ospf-ipv6 permit 233
 match interface bond0.233
 match ipv6 address prefix-list allowed-ospf-vlan233

[taspelund]

Can you provide the output of show ipv6 route and show ipv6 ospf database?

[laxxie]

I grepped for the prefixes, if yyou need sth other please write me what you need.
Both prefixes are there

root@:~# vtysh -c "sh ipv6 ospf database " | grep TTT
ASE  0.0.0.4        lo  1577 80000153           2a00:TTT:YYY::/126
ASE  0.0.0.5        lo  1577 80000153           2a00:TTT:XXX::/126
 
root@:~# vtysh -c "sh ipv6 route" | grep TTT
C>* 2a00:TTT:YYY::/126 is directly connected, bond0.233, 01w0d01h
S>* 2a00:TTT:XXX::/126 [1/0] via 2a00:TTT:YYY::2, bond0.233, weight 1, 01w0d01h

And just to be clear again, it's just the routed prefix 2a00:TTT:XXX::/126 which cannot been seen on other routers.

> show route 2a00:TTT:YYY::

inet6.0: 190558 destinations, 425826 routes (190495 active, 1 holddown, 94 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

2a00:TTT:YYY::/126
                   *[OSPF3/150] 1w0d 01:38:20, metric 20, tag 0
                    >  to fe80::... via xe-0/1/0.ABC
                       to fe80::... via xe-0/1/4.CBA

> show route 2a00:TTT:XXX::

inet6.0: 190555 destinations, 425813 routes (190493 active, 0 holddown, 94 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

2a00:TTT::/32     *[Static/5] 6w2d 12:07:13, tag 8893
                       Discard

[taspelund]

Can you get the detailed contents of the following LSAs:

• the intra-area prefix LSA for 2a00:TTT:YYY::/126
• the intra-area prefix LSA for 2a00:TTT:XXX::/126
• the router LSA originated by the FRR router

[taspelund]

Ideally from both FRR 8.5.3 and from FRR 9.0.1

[laxxie]

These are the LSA details. sh ipv6 ospf6 database detail

Age: 1464 Type: AS-External
Link State ID: 0.0.0.6
Advertising Router: lo
LS Sequence Number: 0x80000006
CheckSum: 0xc579 Length: 44
Duration: 00:24:23
     Bits: E--
     Metric:    20
     Prefix Options: --|--|--|--|--
     Referenced LSType: 0
     Prefix: 2a00:TTT:YYY::/126

Age: 1463 Type: AS-External
Link State ID: 0.0.0.7
Advertising Router: lo
LS Sequence Number: 0x80000006
CheckSum: 0xc105 Length: 60
Duration: 00:24:23
     Bits: EF-
     Metric:    20
     Prefix Options: --|--|--|--|--
     Referenced LSType: 0
     Prefix: 2a00:TTT:XXX::/126
     Forwarding-Address: 2a00:TTT:YYY::2

There are no intra-prefix LSAs

root@:# vtysh -c "sh ipv6 ospf6 database intra-prefix" | grep TTT
root@:#

FRR 8.5.2

Age:  145 Type: AS-External
Link State ID: 0.0.0.8
Advertising Router: lo
LS Sequence Number: 0x80000001
CheckSum: 0xc181 Length: 44
Duration: 00:02:25
     Bits: E--
     Metric:    20
     Prefix Options: --|--|--|--|--
     Referenced LSType: 0
     Prefix: 2a00:TTT:YYY::/126

Age:  145 Type: AS-External
Link State ID: 0.0.0.9
Advertising Router: lo
LS Sequence Number: 0x80000001
CheckSum: 0xc779 Length: 44
Duration: 00:02:25
     Bits: E--
     Metric:    20
     Prefix Options: --|--|--|--|--
     Referenced LSType: 0
     Prefix: 2a00:TTT:XXX::/126

root@:~# vtysh -c "sh ipv6 ospf6 database intra-prefix" | grep TTT
root@:~#

Obviously the F bit is set @frr9 and @FRR8.5 not

[taspelund]

The OSPFv3 RFC (5340) doesn't give much guidance around when the Forwarding address should be set, aside from the requirement for the F bit to be set along with it:

   Forwarding address
      A fully qualified IPv6 address (128 bits).  Included in the LSA if
      and only if bit F has been set.  If included, data traffic for the
      advertised destination will be forwarded to this address.  It MUST
      NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an
      IPv6 Link-Local Address (Prefix FE80/10).  While OSPFv3 routes are
      normally installed with link-local addresses, an OSPFv3
      implementation advertising a forwarding address MUST advertise a
      global IPv6 address.  This global IPv6 address may be the next-hop
      gateway for an external prefix or may be obtained through some
      other method (e.g., configuration).

It does reference following the procedures from OSPFv2, so I went back to RFC 2328. The only real guidance I could see is that when calculating an AS-External LSA that a non-zero forwarding address must be resolved via an intra-area or inter-area path:

            If the forwarding address is non-zero, look up the
            forwarding address in the routing table.[24] The matching
            routing table entry must specify an intra-area or inter-area
            path; if no such path exists, do nothing with the LSA and
            consider the next in the list.

There's no explicit statement that the FA should only be set when the next-hop of the external route is known via a link advertised in OSPF, just that it should be set the the next-hop of a router in another autonomous system.

If you enable OSPF on the interface where your static routes point to (probably as passive), is your route installation issue resolved?

[laxxie]

If you enable OSPF on the interface where your static routes point to (probably as passive), is your route installation issue resolved?

Yes, if we activate ospf6

interface bond0.233
 ipv6 ospf6 area 0.0.0.0
 ipv6 ospf6 passive

the route is advertised to the Junipers and we see the prefix there.
But is this really the solution? it's a major break as routed v6 prefixes are not routed anymore if you change the version to FRR 9.

[taspelund]

I think it would be reasonable for the FA/F-bit to only be set in External LSAs if the redistributed next-hop is known via an interface with OSPF enabled (i.e. only set F-bit if we know the FA will actually be usable by downstream OSPF routers), but it's not coded that way today and I'm not familiar with the ospf6d code.

Looking back through the git log (I have not done a git bisect or tested the functionality directly), it seems like this commit may have been where this was introduced:

commit 73d9d322fe22c9e357fcc801562ab118f23c1969
Author: Renato Westphal <[email protected]>
Date:   Thu Mar 2 20:20:39 2023 -0300

    ospf6d: originate AS-External LSAs with a forwarding address

    Originate AS-External LSAs with forwarding addresses whenever the
    corresponding redistributed routes have a global nexthop address.

    Signed-off-by: Renato Westphal <[email protected]>

diff --git a/ospf6d/ospf6_asbr.c b/ospf6d/ospf6_asbr.c
index 05275c52e..7ee22e05c 100644
--- a/ospf6d/ospf6_asbr.c
+++ b/ospf6d/ospf6_asbr.c
@@ -1469,9 +1469,13 @@ void ospf6_asbr_redistribute_add(int type, ifindex_t ifindex,

                info->type = type;

-               if (nexthop_num && nexthop)
+               if (nexthop_num && nexthop) {
                        ospf6_route_add_nexthop(match, ifindex, nexthop);
-               else
+                       if (!IN6_IS_ADDR_UNSPECIFIED(nexthop)
+                           && !IN6_IS_ADDR_LINKLOCAL(nexthop))
+                               memcpy(&info->forwarding, nexthop,
+                                      sizeof(struct in6_addr));
+               } else
                        ospf6_route_add_nexthop(match, ifindex, NULL);

                match->path.origin.id = htonl(info->id);
@@ -1515,9 +1519,13 @@ void ospf6_asbr_redistribute_add(int type, ifindex_t ifindex,
        }

        info->type = type;
-       if (nexthop_num && nexthop)
+       if (nexthop_num && nexthop) {
                ospf6_route_add_nexthop(route, ifindex, nexthop);
-       else
+               if (!IN6_IS_ADDR_UNSPECIFIED(nexthop)
+                   && !IN6_IS_ADDR_LINKLOCAL(nexthop))
+                       memcpy(&info->forwarding, nexthop,
+                              sizeof(struct in6_addr));
+       } else
                ospf6_route_add_nexthop(route, ifindex, NULL);

        route = ospf6_route_add(route, ospf6->external_table);

@rwestphal does this ring a bell to you? If so, do you think it's feasible to do a check if the nexthop interface has OSPF enabled before adding the Forwarding Address?