Technical Tip: OSPFv2 ECMP for External Routes Expected Behavior with RFC1583 Compatibility

Anonymous · ‎06-28-2022

Description

This article describes a scenario when external Routes with the same cost 'ECMP' to the ASBRs are not installed on the routing table or database.

Scope

FortiGate.

Solution

OSPF by default works with ECMP RFC 2328 which introduces Intra-area paths using non-backbone areas are most preferred and Intra-area backbone paths and inter-area paths have equal preference. OSPF prefers intra-area routes in non-backbone areas to reduce backbone overhead. As per ECMP RFC 1583, path selection is based solely on cost and can be used to allow FortiGate to install external routes of same cost in the routing database. FortiGate by default has RFC1583 Compatibility disabled hence, it is expected that FortiGate will only install one external route in the routing table even if the cost is equal; however this behavior can be changed by RFC1583 Compatibility configuration by using below:

config router ospf

set rfc1583-compatible enable

end

Note: The above change will force all OSPF adjacencies to restart. Thus, it is highly recommended to make the changes in a scheduled maintenance window.

Troubleshooting steps:

Check the RFC1583 Compatibility status.

config router ospf

get

Check the external LSA, the external routes can be seen in the OSPF external LSA database. The routes should have the same metric to the advertised router and the forwarding address should be 0.0.0.0 in this case.

get router info ospf database external lsa X.X.X.X<-- X.X.X.X is the external route

If the routes in the external LSA are valid with the same cost, the route should be in the routing table if the rfc1583-compatible enable.

As shown in the below topology, FortiGate has two OSPF adjacencies with R1 and R2.

The OSPF area between FortiGate and R1 is area 2 and area 3 between FortiGate and R2, both areas are normal OSPF areas.

However, the areas can be special areas such as stubby or NSSA.

Both R1 and R2 are ASBR, they are redistributing the subnet 172.16.1.1/32 into OSPF from another administrative domain.

Expected Behavior with RFC1583 Compatibility disabled 'default'.

FortiGate-VM64-KVM # config router ospf

FortiGate-VM64-KVM (ospf) # get

rfc1583-compatible : disable

!

FortiGate-VM64-KVM # get router info ospf neighbor

OSPF process 0, VRF 0:

Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 1 Full/ - 00:00:34 192.168.22.1 port2

3.3.3.3 1 Full/ - 00:00:36 192.168.33.1 port3

!

FortiGate-VM64-KVM # get router info routing-table details

Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP

O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default

Routing table for VRF=0

O E2 172.16.1.1/32 [110/20] via 192.168.33.1, port3, 00:00:44 ---> only one route in the routing table via area3

C 192.168.10.0/24 is directly connected, port1

C 192.168.22.0/24 is directly connected, port2

C 192.168.33.0/24 is directly connected, port3

!

FortiGate-VM64-KVM # get router info ospf database external lsa 172.16.1.1

AS External Link States ---> OSPF database learnt the route 172.16.1.1 via the two adjacencies.

LS age: 1732

Options: 0x20 (*|-|DC|-|-|-|-|-)

LS Type: AS-external-LSA

Link State ID: 172.16.1.1 (External Network Number)

Advertising Router: 2.2.2.2

LS Seq Number: 80000001

Checksum: 0x11c8

Length: 36

Network Mask: /32

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 20

Forward Address: 0.0.0.0

External Route Tag: 0

LS age: 1759