For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

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

    • 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