Regression in OSPF since 7.12 (7.13rc3 too)

michald · Mon Dec 11, 2023 12:44 pm

I've problem with IPv6 based OSPF protocol since upgrade to 7.12 (the same with all newer versions including 7.13rc3).

I have a quiet simple OSPF star topology. hEX POE is the central node, three WiFi APs as satellites (hAP ac^2, hAP ac lite, SXTsq Lite2). Area 0 only.

The problem reveals itself so far only between hEX and hAP ac lite.

After synchronous power-on of all nodes everything is fine. The OSPF routes are as below:

hEX:

> /ipv6/route/print where ospf
DAo  fd00::10/128  fe80::764d:28ff:fe36:3a0%ether2        110
DAo  fd00::11/128  fe80::2ec8:1bff:fe83:ddb5%ether3       110
DAo  fd00::12/128  fe80::c6ad:34ff:fed6:cbaa%ether4       110
DIoH fd03::/64     brVPLS                                 110
DIoH fd04::/64     sit0                                   110

hAP lite:

DAo  fd00::1/128   fe80::a55:31ff:fe78:1d49%ether1       110
DAo  fd00::10/128  fe80::a55:31ff:fe78:1d49%ether1       110
DAo  fd00::12/128  fe80::a55:31ff:fe78:1d49%ether1       110
DIoH fd03::/64     brVPLS                                110

The OSPF works directly on the physical interfaces (ether2, ether3, ether4 on hEX, ether1 on all satellites) declared as ptp.

Every node has a loopback (fd00::x/128) added to the OSPF as a passive interface. There is also brVPLS bridge interface (fd03::/64) on any node and SIT tunnel interface on hEX, all OSPF passive.

No any redistribution to OSPF.

After couple of hours or a day or two hAP lite stops responding to pings from central hEX to its loopback (fd00::11). All WiFi clients connected to it lose their connection to the Internet.

The hEX OSPF routes changes to this:

DAo  fd00::10/128  fe80::764d:28ff:fe36:3a0%ether2        110
DAo  fd00::12/128  fe80::c6ad:34ff:fed6:cbaa%ether4       110
DIoH fd03::/64     brVPLS                                 110
DAo  fd03::11/128  fe80::2ec8:1bff:fe83:ddb5%ether3       110
DIoH fd04::/64     sit0                                   110

As you can see fd00::11/128 and fd03::/64 disappeared and fd03::11/128 appeared.

I even once caught cd03::11/128 (there is no such address configured on any node):

DAo  fd00::10/128  fe80::764d:28ff:fe36:3a0%ether2        110
DAo  fd00::12/128  fe80::c6ad:34ff:fed6:cbaa%ether4       110
DIoH fd03::/64     brVPLS                                 110
DAo  cd03::11/128  fe80::2ec8:1bff:fe83:ddb5%ether3       110
DIoH fd04::/64     sit0                                   110

But it never came up again.

When this problem arises the relevant LSAs on the central hEX look like this:

> /routing/ospf/lsa/print where body~"fd0"
Flags: S - self-originated, F - flushing, W - wraparound; D - dynamic 
 4 SD instance=ospf1 area=ospf1-area0 type="intra-area-prefix" originator=10.234.0.1 id=0.0.0.0 sequence=0x8000003B 
      age=1029 checksum=0xD2E4 body=
        ref-type=router
        ref-id=0.0.0.0
        ref-router-id=10.234.0.1
            prefix=fd00::1 options=LA
            prefix=fd04::/64
            prefix=fd03::/64

 5  D instance=ospf1 area=ospf1-area0 type="intra-area-prefix" originator=10.234.0.10 id=0.0.0.0 sequence=0x80000036 
      age=271 checksum=0xAC3F body=
        ref-type=router
        ref-id=0.0.0.0
        ref-router-id=10.234.0.10
            prefix=fd00::10 options=LA
            prefix=fd03::/64

 6  D instance=ospf1 area=ospf1-area0 type="intra-area-prefix" originator=10.234.0.11 id=0.0.0.0 sequence=0x8000001A 
      age=28 checksum=0x15EC body=
        ref-type=router
        ref-id=0.0.0.0
        ref-router-id=10.234.0.11
            prefix=fd03::/64
            prefix=fd03::11 options=LA

 7  D instance=ospf1 area=ospf1-area0 type="intra-area-prefix" originator=10.234.0.12 id=0.0.0.0 sequence=0x80000036 
      age=738 checksum=0x1E4 body=
        ref-type=router
        ref-id=0.0.0.0
        ref-router-id=10.234.0.12
            prefix=fd00::12 options=LA
            prefix=fd03::/64

As you can see hEX claims to receive fd03::/64 and fd03::11 from hAP lite:

 6  D instance=ospf1 area=ospf1-area0 type="intra-area-prefix" originator=10.234.0.11 id=0.0.0.0 sequence=0x8000001A 
      age=28 checksum=0x15EC body=
        ref-type=router
        ref-id=0.0.0.0
        ref-router-id=10.234.0.11
            prefix=fd03::/64
            prefix=fd03::11 options=LA

When everything works fine it looks like this:

 2  D instance=ospf1 area=ospf1-area0 type="intra-area-prefix" originator=10.234.0.11 id=0.0.0.0 sequence=0x80000003 age=596 checksum=0x3DDE 
      body=
        ref-type=router
        ref-id=0.0.0.0
        ref-router-id=10.234.0.11
            prefix=fd00::11 options=LA
            prefix=fd03::/64

When this problem arises, disabling and enabling OSPF instance on the central hEX or hAP lite doesn't help. What helps is synchronous reboot of both devices.

Regression in OSPF since 7.12 (7.13rc3 too)

Regression in OSPF since 7.12 (7.13rc3 too)

Who is online