Re-advertising routes to OSPF includes /32 host routes which override networks

[David_Herselman]

We recently switched R80.40 gateways running JHA take 118 (latest) from MPLS BGP controlled routing to using OSPF over IPSec tunnels using VTIs.

A problem we observed was that re-advertised BGP or static routes would appear in the OSPF database as host routes for the relevant network. I mean by this that a re-advertised static route for eg 192.168.131.0/24 would get installed as a route to 192.168.131.0/32, making hosts in this subnet unreachable.

I found sk117693 (https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...) but the router-id is correctly set as the VIP on both cluster members (we have 4 clustered gateways).

Work around was to construct a filter to exclude /32 (255.255.255.255) routes when processing OSPF LSAs:

set inbound-route-filter ospf2 instance default restrict-all-ipv4
set inbound-route-filter ospf2 instance default route 10.0.0.0/8 between 8 and 31 on
set inbound-route-filter ospf2 instance default route 172.16.0.0/12 between 12 and 31 on
set inbound-route-filter ospf2 instance default route 192.168.0.0/16 between 16 and 31 on

Is this a known issue?

Sample config on gateway originating connected, static and BGP routes:

set router-id 41.1.1.1
set bgp external remote-as 65000 on
set bgp external remote-as 65000 description "Interbranch eBGP"
set bgp external remote-as 65000 peer 192.168.100.6 on
set bgp external remote-as 65000 peer 192.168.100.6 route-refresh on
set bgp external remote-as 65000 peer 192.168.100.6 import-routemap "bgp-inbound" preference 1 on
set route-redistribution to bgp-as 65000 from interface all on
set route-redistribution to bgp-as 65000 from static-route all-ipv4-routes on
set route-redistribution to bgp-as 65000 from ospf2 instance default all-ipv4-routes on
set route-redistribution to bgp-as 65000 from ospf2ase instance default all-ipv4-routes on
set routemap bgp-inbound id 1 on
set routemap bgp-inbound id 1 allow
set ospf instance default area backbone on
set ospf instance default interface vpnt3 area backbone on
set ospf instance default interface vpnt3 hello-interval 1
set ospf instance default interface vpnt3 dead-interval 10
set ospf instance default interface vpnt3 cost 10
set ospf instance default interface vpnt3 priority 1
set ospf instance default interface vpnt3 authtype cryptographic key 1 algorithm md5 secret already_scrambled_xxxxxxxxxxxxxxxxxxxxxx==_00000000000000000000000000000000000000
set ospf instance default area backbone range 192.168.254.1/32 restrict on
set route-redistribution to ospf2 instance default from interface all on
set route-redistribution to ospf2 instance default from static-route all-ipv4-routes on
set route-redistribution to ospf2 instance default from bgp-as-number 65000 all-ipv4-routes on
set inbound-route-filter ospf2 instance default restrict-all-ipv4
set inbound-route-filter ospf2 instance default route 10.0.0.0/8 between 8 and 31 on
set inbound-route-filter ospf2 instance default route 172.16.0.0/12 between 12 and 31 on
set inbound-route-filter ospf2 instance default route 192.168.0.0/16 between 16 and 31 on

Regards

David Herselman

[PhoneBoy]

Maybe the fact it wasn't propagating the routes before was a bug that we fixed.
Are you sharing your static routes with OSPF in this case?

[David_Herselman]

Hi,

I believe this to be a bug, we are very accustomed to working with OSPF2 on a variety of different routing platforms where we regularly distribute to OSPF connected and static routes. The problem with R80.40 does not appear to relate to JHA take 118 as I hit this issue once before and worked around it, surprised to still see this being an issue but didn't log it with TAC as I assumed this common scenario to affect countless other customers as well...

To clarify, the following:

set static-route 192.168.50.0/24 nexthop gateway address 100.127.254.1 on
set route-redistribution to ospf2 instance default from static-route all-ipv4-routes on

Correctly creates type-5 AS external Link State:

Type-5 AS External Link States

Link State Type:     AS External Link
Link State ID:       192.168.50.0
LS Age:              957
Options:             ASE
Advertising Router:  100.127.254.2
LS Seq Num:          0x8000001e
CheckSum:            0x679d
Length:              36
Network Mask: 255.255.255.0
Metric Type: 1
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 0x00000000

It however also creates the following, which then overrides the valid OSPF LSA on the other devices:

Type-5 AS External Link States

Link State Type:     AS External Link
Link State ID:       192.168.50.0
LS Age:              957
Options:             ASE
Advertising Router:  100.127.254.2
LS Seq Num:          0x8000001g
CheckSum:            0xe687
Length:              36
Network Mask: 0.0.0.0
Metric Type: 1
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 0x00000000

At least the OSPF2 filtering mechanism appear to apply to received OSPF LSAs and not the routes OSPF attempts to install in to the local system's routing table from the LSA database. By filtering all LSAs with a network mask of 0.0.0.0 (/32) works around the issue.

[PhoneBoy]

That definitely sounds like a bug worthy of a TAC case.

[Sam2]

Hi, was a case for this made? We faced the same issue this weekend on R80.10.