ospf external type 2 and igp_metric

[Ondrej Zajicek]

On Thu, Jul 29, 2021 at 03:14:39PM -0400, Dave Johnson wrote:
> 
> 
> Hi,
> 
> I'm trying to get igp_metric to work for iBGP based on an OSPF
> metric.
> 
> 
> Here's my setup:
> 
> I would like to make use of the iBGP igp_metric as a tie-breaker if
> BGP gets down that far in the route selection process, however I can't
> seem to get BGP to pick up the OSPF metric for other machine's
> loopbacks.


> The loopback is being imported using a proto direct as it's simply
> from Linux's lo interface:
> 
>   root at archer:~# birdc show route 10.10.10.30/32 all
>   BIRD 1.6.6 ready.
>   10.10.10.30/32     dev lo [direct1 11:14:34] * (240)
>           Type: device unicast univ
>   root at archer:~# 

Hi

I would suggest to just set loopback as a stub iface in OSPF. You would
end with regular OSPF route instead of OSPF-E2 route and it would be
more consistent with how OSPF is supposed to used.

There were some issues that BIRD did not allow 'lo' as its iface (i think
we changed that in some 2.0.x version but probably it is still true in
1.6.x version). In such case the simplest way is to use dummy iface
instead of loopback iface.

> When viewed from another machine via ospf, this route now shows as an
> external type 2 route.  The OSPF.metric1 of 26 is correct:
> 
>   root at ganges:~# birdc show route 10.10.10.30/32 all
>   BIRD 1.6.6 ready.
>   10.10.10.30/32     via 10.10.13.1 on tun13 [ospf1 11:14:35] * E2 (150/26/10000) [10.10.10.30]
>           Type: OSPF-E2 unicast univ
>           OSPF.metric1: 26
>           OSPF.metric2: 10000
>           OSPF.tag: 0x00000000
>           OSPF.router_id: 10.10.10.30
>   root at ganges:~# 
> 
> 
> So when I'm trying to use iBGP this OSPF.metric1 should be taken into
> account as the igp_metric right?

No. The real OSPF metric is pair (10000, 26), where metric2 is more
important. So one cannot (in general) just ignore ospf_metric2 and use
ospf_metric1.

If you have another route that has ospf_metric2 = 5000 and
ospf_metric1 = 126, then it shoud be preferred above the one with
(10000, 26).


> I would expect this to work based on rt_get_igp_metric() however that
> function doesn't include pulling an OSPF metric from RTS_OSPF_EXT2
> type routes (only type 1).
> 
>   #ifdef CONFIG_OSPF
>     if ((a->source == RTS_OSPF) ||
>         (a->source == RTS_OSPF_IA) ||
>         (a->source == RTS_OSPF_EXT1))
>       return rt->u.ospf.metric1;
>   #endif
> 
> Is there some reason RTS_OSPF_EXT2 isn't included here?  Even
> RTS_OSPF_EXT2 routes have an OSPF.metric1.

That is intentional. As noted above, both ospf_metric1 and ospf_metric2
are important for OSPF-E2 routes, so fair mapping of OSPF metrics to
igp_metric would be like ospf_metric2 * max_metric1 + ospf_metric1. But
that would not fit to igp_metric range and OSPF-E2 routes are generally
not supposed to be used in cases where this matter, so we do not set
igp_metric and treat it as 'infinity'.

If one really needs igp_metric for OSPF-E2 routes, one can set it in OSPF
import filter (igp_metric = <some expression>;).


> I've tried to work around type by doing 2 things:
> 
> 1st, trying to get the routes to show up as an external type 1 instead
> of type 2, but I dont see how in the config.

That is a good idea (if the approach by announcing these ifaces
as OSPF stub ifaces is not applicable).

This is kind of tricky, but algorithm in v1.6.* is if you set (during
export) ospf_metric1, then it is announced as OSPF-E1 route, otherwise as
OSPF-E2 route.

You can simply set 'osp_metric1 = 0; accept;' in OSPF export filter.
The value is additional metric respresenting the rest of route, regular
OSPF metric will be added to that.


> 2nd, setting igp_metric manually in an import/export filter, however
> that doesn't seem to work either.

Well, that should work. Will try that.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."