ROS v7 - OSPF - Area Range - Bug

I’m doing a laboratory with OSPF Multi areas, using version 7 when I use the “area range” route summary feature on the ABR Router, I get a bug, if I configure it in area range e.g.: 10.10.4.0/23, the ABR does not propagate the ads, now if I put 10.10.0.0/16 it works

It would be really helpful for other users facing similar issues if you could share the solution as well.

reboot srsrsrrs

Thanks! RoS version?

I might encounter the same problem.

The ABR(rb450gx4 , fw: 7.16.2) has 192.168.8.0/24, 192.168.9.0/24, 192.168.10.0/24 and 192.168.11.0/24. I create an area range item: 192.168.8.0/22 adv=yes, but ospf propagate the wrong lsa:

[admin@rb450gx4-hkjm] /routing/ospf/interface> print
Flags: D - dynamic 
 0 D address=192.168.9.254%vlan9 area=10.8.0.0 state=passive network-type=broadcast cost=1 priority=128 use-bfd=no 
     retransmit-interval=5s transmit-delay=1s hello-interval=10s dead-interval=40s 

 1 D address=192.168.10.254%vlan10 area=10.8.0.0 state=passive network-type=broadcast cost=1 priority=128 use-bfd=no 
     retransmit-interval=5s transmit-delay=1s hello-interval=10s dead-interval=40s 

 2 D address=192.168.11.254%vlan11 area=10.8.0.0 state=passive network-type=broadcast cost=1 priority=128 use-bfd=no 
     retransmit-interval=5s transmit-delay=1s hello-interval=10s dead-interval=40s 

 3 D address=192.168.8.254%vlan8 area=10.8.0.0 state=passive network-type=broadcast cost=1 priority=128 use-bfd=no 
     retransmit-interval=5s transmit-delay=1s hello-interval=10s dead-interval=40s 

 4 D address=172.29.100.9%wg109 area=0.0.0.0 state=ptp network-type=ptp cost=106 use-bfd=no retransmit-interval=5s 
     transmit-delay=1s hello-interval=10s dead-interval=40s 

 5 D address=172.29.100.1%wg101 area=0.0.0.0 state=ptp network-type=ptp cost=101 use-bfd=no retransmit-interval=5s 
     transmit-delay=1s hello-interval=10s dead-interval=40s 

 6 D address=172.29.100.5%wg105 area=0.0.0.0 state=ptp network-type=ptp cost=105 use-bfd=no retransmit-interval=5s 
     transmit-delay=1s hello-interval=10s dead-interval=40s 

[admin@rb450gx4-hkjm] /routing/ospf/area/range> print
Flags: A - ADVERTISE
Columns: AREA, PREFIX
#   AREA      PREFIX        
0 A 10.8.0.0  192.168.8.0/22

[admin@rb450gx4-hkjm] /routing/ospf/lsa> print where id=192.168.8.0 
Flags: S - self-originated, F - flushing, W - wraparound; D - dynamic 
 0 SD instance=ospf-instance-1 area=0.0.0.0 type="inter-area-prefix" originator=10.8.0.100 id=192.168.8.0 sequence=0x80002963 
      age=225 checksum=0x27C4 body=
        netmask=255.255.255.0
        metric=1

I have been reboot the routerboard, no suprised.
any suggestion?

Set value for COST, for example as bellow:

Flags: A - ADVERTISE
Columns: AREA, PREFIX, COST
#   AREA     PREFIX        COST
0 A dt.home  10.21.0.0/16    10

Thanks, but no suprise.
After setup the ABR area range cost. The intra-router’s received lsa indeed change the cost of id=192.168.8.0, but the netmask is still 255.255.255.0, no expected 255.255.252.0

[admin@rb4011-2w] /routing/ospf/lsa> print where id=192.168.8.0
Flags: S - self-originated, F - flushing, W - wraparound; D - dynamic 
 1 SD instance=ospf-instance-1 area=10.12.0.0 type="inter-area-prefix" originator=10.12.0.12 id=192.168.8.0 
      sequence=0x80000009 age=4 checksum=0xF856 body=
        netmask=255.255.255.0
        metric=116

 2  D instance=ospf-instance-1 area=10.12.0.0 type="inter-area-prefix" originator=10.12.0.13 id=192.168.8.0 
      sequence=0x80000009 age=6 checksum=0x1B2F body=
        netmask=255.255.255.0
        metric=120

 3  D instance=ospf-instance-1 area=0.0.0.0 type="inter-area-prefix" originator=10.8.0.100 id=192.168.8.0 
      sequence=0x80000009 age=6 checksum=0xC0A2 body=
        netmask=255.255.255.0
        metric=10

Your area in range setting is difference from area in lsa. Something wrong there.

I dont know why, but finally solve the problem by reboot the router.
It’s definitely a bug.

Necromancing this thread because in 7.13.3 this bug is still not resolved and while googling this issue I stumbled over this conversation.

You don’t have to reboot the machine, disabling and re-enabling the ospf instance you are running the affected area on does the trick, too.