OSPF route selection

[Thomas Goldberg]

Hello,

we're using OSPF for anycast routing and came across a small problem.

We've a BIRD v1.4.4 router which sits in area 0 and 16.
Here's the relevant state information (10.236.144.144/32 is announced
from two different routers in two areas):

area 0.0.0.0
router 10.236.144.241
distance 33
external 10.236.144.144/32 metric 1

area 0.0.0.16
router 10.17.224.253
distance 111
external 10.236.144.144/32 metric 1

The route via area 16 is considered best:
10.236.144.144/32 via 10.176.3.29 on vlan542 [o_internal 2014-10-07
16:49:56] * E1 (150/112) [10.17.224.253]

Given that both E1 routes are reachable via intra-area paths.
We're wondering why the path via area 16 (higher costs than area 0) is chosen.
Is this the intended behavior?
Is there any way to make bird prefer routes via a specific/backbone
area in a situation like this?

Best Regards,
Freddy

[Ondrej Zajicek]

Post by Thomas Goldberg
Hello,
we're using OSPF for anycast routing and came across a small problem.
We've a BIRD v1.4.4 router which sits in area 0 and 16.
Here's the relevant state information (10.236.144.144/32 is announced
area 0.0.0.0
router 10.236.144.241
distance 33
external 10.236.144.144/32 metric 1
area 0.0.0.16
router 10.17.224.253
distance 111
external 10.236.144.144/32 metric 1
10.236.144.144/32 via 10.176.3.29 on vlan542 [o_internal 2014-10-07
16:49:56] * E1 (150/112) [10.17.224.253]
Given that both E1 routes are reachable via intra-area paths.
We're wondering why the path via area 16 (higher costs than area 0) is chosen.
Is this the intended behavior?

Surprisingly yes, see RFC 2328 16.4. (6c) and 16.4.1.:

16.4.1. External path preferences

...

The path preference rules, stated from highest to lowest
preference, are as follows. Note that as a result of these
rules, there may still be multiple paths of the highest
preference. In this case, the path to use must be determined
based on cost, as described in Section 16.4.

o Intra-area paths using non-backbone areas are always the
most preferred.

o The other paths, intra-area backbone paths and inter-
area paths, are of equal preference.

Post by Thomas Goldberg
Is there any way to make bird prefer routes via a specific/backbone
area in a situation like this?

You could enable 'RFC1583Compatibility' option, but that is generally
discouraged unless you know exactly what you are doing (as it may lead
to persistent routing loops).

Or you could use external routes with different E2 metric, in that case
lower E2 metric is always preferred.

[Olivier Benghozi]

Hi ,

it should be noted that the RFC 2328 explains in its annex C.1 that the "RFC1583Compatibility" flag must be "Set to enabled by default".

Most OSPF deployments in the world using hardware equipments are indeed using RFC 1583 behavior set by default (Cisco, Juniper, Brocade, Ericsson, Alcatel...) with some exceptions for some firewalls (Fortinet, Check Point...).
However the main and newer software engines set it to off by default (BIRD, Quagga... and appliances using them in their products).

So if someone is expecting a "usual" behavior (usual from the hardware routers world), the change can be hard to understand.

The critical thing is having that configuration consistant across the network (default values sometimes suck), and understanding what is done (if set to off, the particular loop case design must be avoided).
That particular case of OSPF RFC1583 failure is described by example at https://live.paloaltonetworks.com/docs/DOC-5561


regards,
Olivier

Post by Ondrej Zajicek
You could enable 'RFC1583Compatibility' option, but that is generally
discouraged unless you know exactly what you are doing (as it may lead
to persistent routing loops).

[Ondrej Zajicek]

Post by Olivier Benghozi
Hi ,
it should be noted that the RFC 2328 explains in its annex C.1 that the "RFC1583Compatibility" flag must be "Set to enabled by default".

Thanks, i never noticed that.

Post by Olivier Benghozi
The critical thing is having that configuration consistant across the
network (default values sometimes suck), and understanding what is done
(if set to off, the particular loop case design must be avoided).

This is probably a typo, but the loop case must be avoided when
RFC1583Compatibility is enabled, not when it is turned off.

[Olivier Benghozi]

Post by Ondrej Zajicek

Post by Olivier Benghozi
it should be noted that the RFC 2328 explains in its annex C.1 that the "RFC1583Compatibility" flag must be "Set to enabled by default".

Thanks, i never noticed that.

And some codes don't even allow to switch it off (Ericsson/Redback...) :-/

Post by Ondrej Zajicek

Post by Olivier Benghozi
The critical thing is having that configuration consistant across the
network (default values sometimes suck), and understanding what is done
(if set to off, the particular loop case design must be avoided).

This is probably a typo, but the loop case must be avoided when
RFC1583Compatibility is enabled, not when it is turned off.

Right, if set to On :)