ospf external type 2 and igp_metric
Hi, I'm trying to get igp_metric to work for iBGP based on an OSPF metric. Here's my setup: I'm using OSPF for an IGP, eBGP on border machines for internet routes, and iBGP within to select the best border for traffic not covered internally with OSPF. OSPF is using connected IPs for broadcast and tunnel interfaces and each machine also includes a static loopback IP for general communication including iBGP. iBGP is setup to communicate from/to each machine's loopback IP to be immune from any connected network or tunnel disruption. OSPF is propigating reachability to each loopback just ok. 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@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@archer:~# 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@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@ganges:~# So when I'm trying to use iBGP this OSPF.metric1 should be taken into account as the igp_metric right? 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. For example, here's an arbitrary internet route that has equal local preference, equal path lengths, both IGP, no MED, etc.. so igp would be a deciding factor here. 10.10.10.30 and 10.10.10.31 are border routers, and this command is run on a interior router: root@ganges:~# birdc show route 128.0.128.0/20 table internet all BIRD 1.6.6 ready. 128.0.128.0/20 via 10.10.13.1 on tun13 [bgp_archer 14:50:00 from 10.10.10.30] * (100/?) [AS25513i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 64515 65534 20473 8359 25513 BGP.next_hop: 10.10.10.30 BGP.local_pref: 100 BGP.community: (20473,200) (64515,44) via 10.10.13.1 on tun13 [bgp_reliant 14:50:00 from 10.10.10.31] (100/?) [AS25513i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65002 65001 21700 8359 25513 BGP.next_hop: 10.10.10.31 BGP.local_pref: 100 BGP.community: (0,199) (8359,100) (8359,5500) (8359,55277) BGP.large_community: (21700, 101, 3) (21700, 102, 840) (21700, 103, 1) root@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@ganges:~# birdc show route 10.10.10.31/32 all BIRD 1.6.6 ready. 10.10.10.31/32 via 10.10.13.1 on tun13 [ospf1 2021-07-26] * E2 (150/15/10000) [10.10.10.31] Type: OSPF-E2 unicast univ OSPF.metric1: 15 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.10.31 root@ganges:~# Note that the igp_metric is '?' for both, and the route via 10.10.10.30 is selected even though the OSPF metric is higher for that. 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. 2nd, setting igp_metric manually in an import/export filter, however that doesn't seem to work either. I'm using debian's bird 1.6. Thoughts? -- Dave
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@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@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@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@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@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."
Ondrej Zajicek writes:
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@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@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.
Thanks a bunch, using an ospf stub instead of direct did the trick: root@ganges:~# birdc show route 128.0.128.0/20 table internet all BIRD 1.6.6 ready. 128.0.128.0/20 via 10.10.13.1 on tun13 [bgp_reliant 14:50:00 from 10.10.10.31] * (100/15) [AS25513i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65002 65001 21700 8359 25513 BGP.next_hop: 10.10.10.31 BGP.local_pref: 100 BGP.community: (0,199) (8359,100) (8359,5500) (8359,55277) BGP.large_community: (21700, 101, 3) (21700, 102, 840) (21700, 103, 1) via 10.10.13.1 on tun13 [bgp_archer 14:50:00 from 10.10.10.30] (100/26) [AS25513i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 64515 65534 20473 8359 25513 BGP.next_hop: 10.10.10.30 BGP.local_pref: 100 BGP.community: (20473,200) (64515,44) root@ganges:~# -- Dave
participants (2)
-
Dave Johnson -
Ondrej Zajicek