Forum Discussion

mlwebster's avatar
mlwebster
Icon for Cirrus rankCirrus
Jan 03, 2024

F5 appliances failing to establish OSPF with attached devices

Hi all,

there is a little known 'feature' in the underlying Linux OS that has a hard limit of 20 network statements.

If you go beyond 20, the additional networks will not be advertised in OSPF.

I hit this limit after migrating services to my Big-IP.  It took F5 support a while to find the cause as the feature isn’t widely known within F5 despite been over 10 years old.

My workaround was to super-net a number of /24 subnets into /20, /21 statements which brought me back under the limit of 20 networks (conf t network statements in imish).

If this isn’t possible you need to change the net.ipv4.igmp_max_memberships configuration & restart the OSPF process

sysctl net.ipv4.igmp_max_memberships=25

zebos -r 0 cmd clear ip ospf process

 show ip ospf neighbor

Above I am setting the hard limit to 25 networks & restarting the OSPF process. 

Note, adding with sysctl should allow the setting to survive a restart/upgrade – omit it & the increase will not survive a reboot.

Showing the neighborships will now show expected results for the missing networks (statements 21-25)

application delivery
network
ospf

4 Replies

Sort By
    • mlwebster's avatar
      mlwebster
      Icon for Cirrus rankCirrus
      Jan 03, 2024

      Thanks for the article link - I'd already seen that before raising issue with F5 Support.   

      This is to let the community know of the limitation as it isn't documented anywhere & even within F5 support it isn't widely known.

      👍

    • mlwebster's avatar
      mlwebster
      Icon for Cirrus rankCirrus
      Jan 04, 2024

      Hi,

      the networks are all in the same area

      pre super-netting (21 statements)

      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/28 area n
      networks 10.x.x.0/22 area n
      networks 192.168.x.0/29 area n

      here, the 192.168 subnet wasn’t advertised

       

      post super-netting (12 statements)

      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/24 area n
      networks 10.x.x.0/20 area n
      networks 10.x.x.0/21 area n
      networks 10.x.x.0/28 area n
      networks 10.x.x.0/22 area n
      networks 192.168.x.0/29 area n

      now working fine

      If I was unable to super-net I’d need to use – I tested this before implementing the super-netting

      net.ipv4.igmp_max_memberships=25 (>20)

Related Content