Hello, I am trying to set MED on a BGP route using the metric value from OSPF, but the attributes of the next-hop route do not seem to be available in filter evolution. Am I missing something? Example Bird 2.0 config: protocol bgp test_peer { bfd on; med metric on; graceful restart on; ipv4 { table test_table; gateway recursive; }; local as 65656; } protocol ospf t1_igp { ipv4 { table test_table; }; } OSPF is distributing loopbacks and link nets only. BGP protocols from ‘test_peer’ will use routes learned from ‘t1_igp’ in ‘test_table’ to resolve next hop information (gateway recursive). So far, so good. However, I also have an eBGP peer (i.e. who is not participating in my IGP above) who is multi homed with AS65656. I would like to use MED to inform the peer about my IGP distances to each exit — something like the ‘metric-out minimum-igp <offset>’ command in Junos (https://www.juniper.net/documentation/en_US/junos/topics/reference/configura...):
You can increase or decrease the variable metric calculated from the IGP metric (either from the igp or minimum-igp statement) by specifying a value for offset. The metric is increased by specifying a positive value for offset, and decreased by specifying a negative value for offset.
The problem seems to be that filters may only access attributes of the route currently processed, and the 'gateway recursive’ channel directive only calculates next-hop without passing any route attributes of that next-hop through. Has anyone had any luck trying something similar? Many thanks.
On Fri, Mar 22, 2019 at 12:54:57PM -0500, Corban Johnson wrote:
Hello, I am trying to set MED on a BGP route using the metric value from OSPF, but the attributes of the next-hop route do not seem to be available in filter evolution. Am I missing something?
The problem seems to be that filters may only access attributes of the route currently processed, and the 'gateway recursive’ channel directive only calculates next-hop without passing any route attributes of that next-hop through.
Hello Yes, that is true, the value is even stored with the route, it is just not accessible from filters. If you want, i can send you patch to fix 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."
If you want, i can send you patch to fix that.
That would be very helpful, thank you :)
On Mar 22, 2019, at 14:53, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Mar 22, 2019 at 12:54:57PM -0500, Corban Johnson wrote:
Hello, I am trying to set MED on a BGP route using the metric value from OSPF, but the attributes of the next-hop route do not seem to be available in filter evolution. Am I missing something?
The problem seems to be that filters may only access attributes of the route currently processed, and the 'gateway recursive’ channel directive only calculates next-hop without passing any route attributes of that next-hop through.
Hello
Yes, that is true, the value is even stored with the route, it is just not accessible from filters. If you want, i can send you patch to fix 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."
On Fri, Mar 22, 2019 at 02:56:21PM -0500, Corban Johnson wrote:
If you want, i can send you patch to fix that.
That would be very helpful, thank you :)
Attached (untested). It adds read-only integer property nh_cost to access that. The name of the property is horrible (that is why the patch is not commited), i would be glad for a better idea. Unfortunately, 'igp_metric' cannot be used (as it represent the original property of OSPF routes, which is technically a different property with a different access code). -- 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."
I was a curious about the purpose of ‘igp_metric’ attribute while investigating this. It seems to only be used as a generic container attribute in route.h. Is there a reason that property is not exposed? Maybe ‘igp_cost’? :)
On Mar 22, 2019, at 15:10, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Mar 22, 2019 at 02:56:21PM -0500, Corban Johnson wrote:
If you want, i can send you patch to fix that.
That would be very helpful, thank you :)
Attached (untested).
It adds read-only integer property nh_cost to access that.
The name of the property is horrible (that is why the patch is not commited), i would be glad for a better idea. Unfortunately, 'igp_metric' cannot be used (as it represent the original property of OSPF routes, which is technically a different property with a different access code).
-- 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." <igp_metric.patch>
Hello, Any news about implementing solution for IGP MED to MED ? Or do you have patch for 2.X ? Regards, KK W dniu 22.03.2019 o 21:25, Corban Johnson pisze:
I was a curious about the purpose of ‘igp_metric’ attribute while investigating this. It seems to only be used as a generic container attribute in route.h. Is there a reason that property is not exposed?
Maybe ‘igp_cost’? :)
On Mar 22, 2019, at 15:10, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Mar 22, 2019 at 02:56:21PM -0500, Corban Johnson wrote:
If you want, i can send you patch to fix that. That would be very helpful, thank you :) Attached (untested).
It adds read-only integer property nh_cost to access that.
The name of the property is horrible (that is why the patch is not commited), i would be glad for a better idea. Unfortunately, 'igp_metric' cannot be used (as it represent the original property of OSPF routes, which is technically a different property with a different access code).
-- 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." <igp_metric.patch>
-- Pozdrawiam, Konrad Kręciwilk Inżynier sieci GSM +48 883 131 165 tel.: +48 71 735 15 31 e-mail: konrad.kreciwilk@korbank.pl
participants (3)
-
Corban Johnson -
Konrad Kręciwilk -
Ondrej Zajicek