OSPF: Route attribute "ospf_tag" lost between different OSPF instances
Hello! I believe that I'm a user with BIRD experiences but current I have no idea why the attribute "ospf_tag" from one OSPF instance to another is unavailable. In this real life example you can see that I receive a default route from my ISP that is tagged with "7b". This tag is not visible on the VPN client. I use for each VPN network a OSPF instance with some filter rules but only static routes (Core VPN) with a "ospf_tag" are usable to filter like "if ospf_tag = xyz then ..." How can I exchange routes based on a "ospf_tag" between two or more OSPF router instances? [Core VPN Router] BIRD 1.6.0 ready. 0.0.0.0/0 via 82.206.X.33 on lagg0 [titan 2016-12-25] * E2 (150/5/10) [7b] [217.173.X.190] [VPN Client] BIRD 1.6.0 ready. 0.0.0.0/0 via 10.82.16.1 on tun2 [lte 00:28:10] * E1 (150/5) [82.206.X.34] via 10.82.17.1 on tun3 [umts 00:28:11] E1 (150/10) [82.206.X.34] -- Static-Tagging Works Fine --- route 11.0.0.0/8 via 82.206.X.33 { ospf_tag=16170; }; filter openvpn9x16171_export { if net = 0.0.0.0/0 then { ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } // [...] if ospf_tag = 16171 then { <== WORKS FINE because static route ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } reject; } -- Best regards, Markus
On Tue, Dec 27, 2016 at 07:38:35PM +0100, markus/grundmann wrote:
Hello!
I believe that I'm a user with BIRD experiences but current I have no idea why the attribute "ospf_tag" from one OSPF instance to another is unavailable.
Hello The issue here is that route export to OSPF is a bit counterintuitive. Instead of keeping the attributes (like e.g. when route is reexported between BGP protocols), OSPF attributes are reset before export filters are executed. So both tag and metric is lost when an OSPF route is propagated between OSPF instances. There is a hardcoded exception for static routes, so you could set OSPF attributes for them directly for static protocols. The origin of this behavior is probably intentional (i am not sure), but it seems to me that it is confusing, i would assume that a route attribute would keep existing unless explicitly modified. It is one behavior i would like to change in the future. Question is what is a good default behavior when route is propagated between OSPF instances. Should routes keep their tags and metrics? That might be confusing as the metric may have different interpretations. Also received Ext2 route has both metric2 and metric1 part, but the second one have to be forgotten during reexport. Or should we have two different classes of OSPF route attributes (say ospf_tag and ospf_rcv_tag) to avoid such automatic attribute reexport without attribute modification magic? -- 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 tried to use this "variable" ;-) *lol* [snip] if ospf_rcv_tag = 510 then { ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } [/snap] Reading configuration from /usr/local/etc/bird.conf /usr/local/etc/bird.conf, line 275: ospf_rcv_tag: variable expected. That's the feature I want. Where can I post a feature request??? :-) Regards, Markus On 28.12.2016 00:01, Ondrej Zajicek wrote:
On Tue, Dec 27, 2016 at 07:38:35PM +0100, markus/grundmann wrote:
Hello!
I believe that I'm a user with BIRD experiences but current I have no idea why the attribute "ospf_tag" from one OSPF instance to another is unavailable. Hello
The issue here is that route export to OSPF is a bit counterintuitive. Instead of keeping the attributes (like e.g. when route is reexported between BGP protocols), OSPF attributes are reset before export filters are executed. So both tag and metric is lost when an OSPF route is propagated between OSPF instances. There is a hardcoded exception for static routes, so you could set OSPF attributes for them directly for static protocols.
The origin of this behavior is probably intentional (i am not sure), but it seems to me that it is confusing, i would assume that a route attribute would keep existing unless explicitly modified. It is one behavior i would like to change in the future.
Question is what is a good default behavior when route is propagated between OSPF instances. Should routes keep their tags and metrics? That might be confusing as the metric may have different interpretations. Also received Ext2 route has both metric2 and metric1 part, but the second one have to be forgotten during reexport. Or should we have two different classes of OSPF route attributes (say ospf_tag and ospf_rcv_tag) to avoid such automatic attribute reexport without attribute modification magic?
-- Best regards, Markus Better Privacy with PGP encrypted Mail: http://markusgrundmann.com/pgp/ Fingerprint: 15DE 06CA 3683 C004 0A26 7086 CD81 E5D6 7D2D 4E31 Threema ID: 7ZRET2JY „Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren.“ -- Benjamin Franklin loc: 40.43153,-111.933092
On Wed, Dec 28, 2016 at 12:49:16AM +0100, markus/grundmann wrote:
I tried to use this "variable" ;-) *lol*
[snip] if ospf_rcv_tag = 510 then { ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } [/snap]
That was just a contemplation about possible design options. If you need current time workaround, the simplest way is to abuse some other integer attribute (e.g. bgp_med) to store the value [1] in the import filter of the first OSPF instance, then restore it [2] in the export filter of the second OSPF instance. It is a dirty untested trick, but it should work. [1] bgp_med = ospf_tag; [2] ospf_tag = bgp_med; -- 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 that's sounds good but it will only available for two OSPF instances right? When I use this variable to store the current tag it will override by all other filters. On 28.12.2016 01:25, Ondrej Zajicek wrote:
On Wed, Dec 28, 2016 at 12:49:16AM +0100, markus/grundmann wrote:
I tried to use this "variable" ;-) *lol*
[snip] if ospf_rcv_tag = 510 then { ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } [/snap] That was just a contemplation about possible design options.
If you need current time workaround, the simplest way is to abuse some other integer attribute (e.g. bgp_med) to store the value [1] in the import filter of the first OSPF instance, then restore it [2] in the export filter of the second OSPF instance. It is a dirty untested trick, but it should work.
[1] bgp_med = ospf_tag;
[2] ospf_tag = bgp_med;
-- Best regards, Markus Better Privacy with PGP encrypted Mail: http://markusgrundmann.com/pgp/ Fingerprint: 15DE 06CA 3683 C004 0A26 7086 CD81 E5D6 7D2D 4E31 Threema ID: 7ZRET2JY „Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren.“ -- Benjamin Franklin loc: 40.43153,-111.933092
It works!!! I have tried only from one import-filter to one export-filter and now I see the routes I want. On 28.12.2016 01:28, markus/grundmann wrote:
Ondrej that's sounds good but it will only available for two OSPF instances right? When I use this variable to store the current tag it will override by all other filters.
On 28.12.2016 01:25, Ondrej Zajicek wrote:
On Wed, Dec 28, 2016 at 12:49:16AM +0100, markus/grundmann wrote:
I tried to use this "variable" ;-) *lol*
[snip] if ospf_rcv_tag = 510 then { ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } [/snap] That was just a contemplation about possible design options.
If you need current time workaround, the simplest way is to abuse some other integer attribute (e.g. bgp_med) to store the value [1] in the import filter of the first OSPF instance, then restore it [2] in the export filter of the second OSPF instance. It is a dirty untested trick, but it should work.
[1] bgp_med = ospf_tag;
[2] ospf_tag = bgp_med;
-- Best regards, Markus Better Privacy with PGP encrypted Mail: http://markusgrundmann.com/pgp/ Fingerprint: 15DE 06CA 3683 C004 0A26 7086 CD81 E5D6 7D2D 4E31 Threema ID: 7ZRET2JY „Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren.“ -- Benjamin Franklin loc: 40.43153,-111.933092
It seems very dirty or a failure on my site was done. Currently I'm behind of two OpenVPN-based connections that speaking OSPF. Both links using the ospf_metric1 and ospf_metric2 variables to control the traffic flow. Now I have used additional "bgp_med" on the second OSPF instances and the former routes of the first link was also injected into the FIB of FreeBSD but some seconds later I'm offline *grr*. The default route was delete by bird from the FIB. After I have disabled the second link and set a static route to the VPN gateway I was able to fix the issue on the central VPN *puuuhhh* *its*warm* Here now my feature request *g*... filter foo1_import { if ospf_tag[<label_of_ospf_instace>|<instance_id>] = 123 then accept; if net ~ 10.0.0.0/8 then accept; else reject; } protocol ospf foo2 { label foo2; } Regards, Markus On 28.12.2016 01:33, markus/grundmann wrote:
It works!!! I have tried only from one import-filter to one export-filter and now I see the routes I want.
On 28.12.2016 01:28, markus/grundmann wrote:
Ondrej that's sounds good but it will only available for two OSPF instances right? When I use this variable to store the current tag it will override by all other filters.
On 28.12.2016 01:25, Ondrej Zajicek wrote:
On Wed, Dec 28, 2016 at 12:49:16AM +0100, markus/grundmann wrote:
I tried to use this "variable" ;-) *lol*
[snip] if ospf_rcv_tag = 510 then { ospf_metric1 = SEC_M1_VPN; ospf_metric2 = SEC_M2_VPN; accept; } [/snap] That was just a contemplation about possible design options.
If you need current time workaround, the simplest way is to abuse some other integer attribute (e.g. bgp_med) to store the value [1] in the import filter of the first OSPF instance, then restore it [2] in the export filter of the second OSPF instance. It is a dirty untested trick, but it should work.
[1] bgp_med = ospf_tag;
[2] ospf_tag = bgp_med;
-- Best regards, Markus Better Privacy with PGP encrypted Mail: http://markusgrundmann.com/pgp/ Fingerprint: 15DE 06CA 3683 C004 0A26 7086 CD81 E5D6 7D2D 4E31 Threema ID: 7ZRET2JY „Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren.“ -- Benjamin Franklin loc: 40.43153,-111.933092
participants (2)
-
markus/grundmann -
Ondrej Zajicek