ERR when redistributing to OSPF NSSA
Hello, I've got the problem: I'm trying to reditribute lo-address-es to ospf nssa area:
ifconfig lo0 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet 81.19.70.17 netmask 0xffffffff inet 81.19.70.18 netmask 0xffffffff inet 81.19.94.166 netmask 0xffffffff inet 81.19.94.167 netmask 0xffffffff
bird.conf:
# Override router ID router id 81.19.68.227;
#include filters.conf;
filter ospf_metrics_for_lo0 { # if source != RTS_DEVICE then reject;
if net = 81.19.70.17/32 then { ospf_metric2 = 11; accept "70.17"; } else if net = 81.19.70.18/32 then { ospf_metric2 = 19; accept "70.18"; } else reject; };
# Turn on global debugging of all protocols debug protocols all;
# This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds };
protocol direct { interface "lo0"; }
protocol kernel { # export all; scan time 15; };
protocol ospf { import all; export filter ospf_metrics_for_lo0;
area 70 { nssa; interface "bge0" { hello 1; dead 3; }; }; };
But when I run bird, I've got:
bird -d 29-09-2011 17:34:50 <TRACE> device1: Initializing 29-09-2011 17:34:50 <TRACE> direct1: Initializing 29-09-2011 17:34:50 <TRACE> kernel1: Initializing 29-09-2011 17:34:50 <TRACE> ospf1: Initializing 29-09-2011 17:34:50 <TRACE> device1: Starting 29-09-2011 17:34:50 <TRACE> device1: Scanning interfaces 29-09-2011 17:34:50 <TRACE> device1: State changed to feed 29-09-2011 17:34:50 <TRACE> direct1: Starting 29-09-2011 17:34:50 <TRACE> direct1: State changed to feed 29-09-2011 17:34:50 <TRACE> kernel1: Starting 29-09-2011 17:34:50 <TRACE> kernel1: State changed to feed 29-09-2011 17:34:50 <TRACE> ospf1: Starting 29-09-2011 17:34:50 <TRACE> ospf1: Adding area 0.0.0.70 29-09-2011 17:34:50 <TRACE> ospf1: State changed to feed 29-09-2011 17:34:50 <INFO> Started 29-09-2011 17:34:50 <TRACE> device1: State changed to up 29-09-2011 17:34:50 <TRACE> direct1 < primary address 81.19.68.224/28 on interface bge0 added 29-09-2011 17:34:50 <TRACE> direct1 < primary address 81.19.70.17/32 on interface lo0 added 29-09-2011 17:34:50 <TRACE> direct1 > added [best] 81.19.70.17/32 dev lo0 29-09-2011 17:34:50 <TRACE> direct1 < secondary address 127.0.0.0/8 on interface lo0 added 29-09-2011 17:34:50 <TRACE> direct1 < secondary address 81.19.70.18/32 on interface lo0 added 29-09-2011 17:34:50 <TRACE> direct1 > added [best] 81.19.70.18/32 dev lo0 29-09-2011 17:34:50 <TRACE> direct1 < secondary address 81.19.94.166/32 on interface lo0 added 29-09-2011 17:34:50 <TRACE> direct1 > added [best] 81.19.94.166/32 dev lo0 29-09-2011 17:34:50 <TRACE> direct1 < secondary address 81.19.94.167/32 on interface lo0 added 29-09-2011 17:34:50 <TRACE> direct1 > added [best] 81.19.94.167/32 dev lo0 29-09-2011 17:34:50 <TRACE> direct1: State changed to up 29-09-2011 17:34:50 <TRACE> kernel1: Connected to table master 29-09-2011 17:34:50 <TRACE> kernel1 < rejected by protocol 81.19.70.18/32 dev lo0 29-09-2011 17:34:50 <TRACE> kernel1 < rejected by protocol 81.19.70.17/32 dev lo0 29-09-2011 17:34:50 <TRACE> kernel1 < rejected by protocol 81.19.94.166/32 dev lo0 29-09-2011 17:34:50 <TRACE> kernel1 < rejected by protocol 81.19.94.167/32 dev lo0 29-09-2011 17:34:50 <TRACE> kernel1: State changed to up 29-09-2011 17:34:50 <TRACE> ospf1: Connected to table master 29-09-2011 17:34:50 <TRACE> ospf1 < interface usbus0 created 29-09-2011 17:34:50 <TRACE> ospf1 < interface usbus1 created 29-09-2011 17:34:50 <TRACE> ospf1 < interface bge0 goes up 29-09-2011 17:34:50 <TRACE> ospf1 < primary address 81.19.68.224/28 on interface bge0 added 29-09-2011 17:34:50 <TRACE> ospf1: Adding interface bge0 (81.19.68.224/28) to area 0.0.0.70 29-09-2011 17:34:50 <TRACE> ospf1 < interface bge1 created 29-09-2011 17:34:50 <TRACE> ospf1 < interface ipfw0 created 29-09-2011 17:34:50 <TRACE> ospf1 < interface lo0 goes up 29-09-2011 17:34:50 <TRACE> ospf1 < primary address 81.19.70.17/32 on interface lo0 added 29-09-2011 17:34:50 <TRACE> ospf1 < secondary address 127.0.0.0/8 on interface lo0 added 29-09-2011 17:34:50 <TRACE> ospf1 < secondary address 81.19.70.18/32 on interface lo0 added 29-09-2011 17:34:50 <TRACE> ospf1 < secondary address 81.19.94.166/32 on interface lo0 added 29-09-2011 17:34:50 <TRACE> ospf1 < secondary address 81.19.94.167/32 on interface lo0 added 29-09-2011 17:34:50 <INFO> 70.18 29-09-2011 17:34:50 <TRACE> ospf1 < added 81.19.70.18/32 dev lo0 29-09-2011 17:34:50 <TRACE> ospf1: Originating NSSA-LSA for 81.19.70.18/32 29-09-2011 17:34:50 <ERR> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ what is the ERR? 29-09-2011 17:34:50 <INFO> 70.17 29-09-2011 17:34:50 <TRACE> ospf1 < added 81.19.70.17/32 dev lo0 29-09-2011 17:34:50 <TRACE> ospf1: Originating NSSA-LSA for 81.19.70.17/32 29-09-2011 17:34:50 <ERR> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ what is the ERR? 29-09-2011 17:34:50 <TRACE> ospf1 < filtered out 81.19.94.166/32 dev lo0 29-09-2011 17:34:50 <TRACE> ospf1 < filtered out 81.19.94.167/32 dev lo0 29-09-2011 17:34:50 <TRACE> ospf1: State changed to up
And so I don't see this routes. What am I doing wrong?
bird --version BIRD version 1.3.3
uname -a FreeBSD xxxxx 8.2-20110713-SNAP FreeBSD 8.2-20110713-SNAP #0: Wed Jul 13 20:56:12 UTC 2011 root@nat-m1.rambler.ru:/usr/obj/usr/src/sys/DEVEL amd64
-- Fedor Dikarev Rambler Internet Holding
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Bligh wrote:
--On 29 September 2011 17:39:05 +0400 Fedor Dikarev <fe@rambler-co.ru> wrote:
I've got the problem: I'm trying to reditribute lo-address-es to ospf nssa area:
Do you really need such redistribution? Much better thing to do is just adding interface "lo1" { stub; }; to appropriate area.
My understanding was that OSPF NSSA does not work in bird. I'd love to be told I'm wrong!
bird supports NSSA since 1.3.3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EfXAACgkQwcJ4iSZ1q2kGqACaAwKrrcWBGE9HzI3o68FqmaiQ MMgAn3F9UkHeKw3WxaJNZaNT+f215y3N =sHcC -----END PGP SIGNATURE-----
On 29.09.2011 18:15, Alexander V. Chernikov wrote:
Alex Bligh wrote:
--On 29 September 2011 17:39:05 +0400 Fedor Dikarev <fe@rambler-co.ru> wrote:
I've got the problem: I'm trying to reditribute lo-address-es to ospf nssa area: Do you really need such redistribution? Much better thing to do is just adding interface "lo1" { stub; }; to appropriate area. Yes, I really need so -- at production environment part of them must be advertised as NSSA N1 and others as NSSA N2.
My understanding was that OSPF NSSA does not work in bird. I'd love to be told I'm wrong!
bird supports NSSA since 1.3.3
-- Fedor Dikarev Rambler Internet Holding
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fedor Dikarev wrote:
On 29.09.2011 18:15, Alexander V. Chernikov wrote:
Alex Bligh wrote:
--On 29 September 2011 17:39:05 +0400 Fedor Dikarev <fe@rambler-co.ru> wrote:
I've got the problem: I'm trying to reditribute lo-address-es to ospf nssa area: Do you really need such redistribution? Much better thing to do is just adding interface "lo1" { stub; }; to appropriate area. Yes, I really need so -- at production environment part of them must be advertised as NSSA N1 and others as NSSA N2. Okay, there is a small bug in bird preventing actual errors to come up. Patch attached.
Real error is: bird: ospf1: Cannot find forwarding address for NSSA-LSA 81.19.94.167/32 Actual problem with redistribution resides in the following: when ospf comes up it interpretes all its active interfaces as interfaces with DOWN state. Interfaces with DOWN state are skipped on forwarding address lookup (we need to do this since P-bit is set). As a temporary workaround you can do the following: * apply attached patch (it is simple "sed -I'' s/log(L_ERR,/log(L_ERR/") * do birdc -c 'restart direct1' several seconds after bird is started.
My understanding was that OSPF NSSA does not work in bird. I'd love to be told I'm wrong! bird supports NSSA since 1.3.3
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EkHcACgkQwcJ4iSZ1q2mMRQCePOml2ed8mgGc5CFFg1NgqW2p +PMAnRl7+7AdZdYa8qaTpOrkzfPDiNSk =kjxD -----END PGP SIGNATURE----- --- proto/ospf/topology.c.orig 2011-09-11 23:44:45.000000000 +0400 +++ proto/ospf/topology.c 2011-09-29 19:34:49.000000000 +0400 @@ -786,7 +786,7 @@ { if (check_sum_net_lsaid_collision(fn, en)) { - log(L_ERR, "%s: LSAID collision for %I/%d", + log(L_ERR "%s: LSAID collision for %I/%d", p->name, fn->prefix, fn->pxlen); return; } @@ -864,7 +864,7 @@ { if ((type == ORT_NET) && check_sum_net_lsaid_collision(fn, en)) { - log(L_ERR, "%s: LSAID collision for %I/%d", + log(L_ERR "%s: LSAID collision for %I/%d", p->name, fn->prefix, fn->pxlen); return; } @@ -1091,7 +1091,7 @@ fwaddr = find_surrogate_fwaddr(oa); if (ipa_zero(fwaddr)) { - log(L_ERR, "%s: Cannot find forwarding address for NSSA-LSA %I/%d", + log(L_ERR "%s: Cannot find forwarding address for NSSA-LSA %I/%d", p->name, fn->prefix, fn->pxlen); return; } @@ -1102,7 +1102,7 @@ int rv = check_ext_lsa(en, fn, metric, fwaddr, tag); if (rv < 0) { - log(L_ERR, "%s: LSAID collision for %I/%d", + log(L_ERR "%s: LSAID collision for %I/%d", p->name, fn->prefix, fn->pxlen); return; } @@ -1150,7 +1150,7 @@ { if (check_ext_lsa(en, fn, 0, IPA_NONE, 0) < 0) { - log(L_ERR, "%s: LSAID collision for %I/%d", + log(L_ERR "%s: LSAID collision for %I/%d", p->name, fn->prefix, fn->pxlen); return; }
On Thu, Sep 29, 2011 at 07:36:23PM +0400, Alexander V. Chernikov wrote:
Okay, there is a small bug in bird preventing actual errors to come up. Patch attached.
Thanks for this one.
Real error is: bird: ospf1: Cannot find forwarding address for NSSA-LSA 81.19.94.167/32
Actual problem with redistribution resides in the following: when ospf comes up it interpretes all its active interfaces as interfaces with DOWN state. Interfaces with DOWN state are skipped on forwarding address lookup (we need to do this since P-bit is set).
Yes, you are right. I think that a good quick fix is just allow to use addresses from interfaces with DOWN state (patch attached). Note that in usual circumstances on non-vlink iface the DOWN state is just transitional and not really used - if real interface goes down, ospf interface is removed. BTW, there is a similar (but mostly harmless) bug not related to NSSA - if an interface appears and there is a static route configured that goes through that iface, the static protocol receives the iface notification and generates the route, which is propagated to an ospf protocol before the iface notification, so gw is not found and the route is propagated without one. -- 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, --On 29 September 2011 22:50:25 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
BTW, there is a similar (but mostly harmless) bug not related to NSSA - if an interface appears and there is a static route configured that goes through that iface, the static protocol receives the iface notification and generates the route, which is propagated to an ospf protocol before the iface notification, so gw is not found and the route is propagated without one.
That sounds like it might be what I'm seeing (see mail entitled "Directly connected interface redistribution problem" - yes I will get you the debug output you wanted, the test environment got rebuilt before I could get it), as what we're doing is redistributing static routes. Do you have a fix I could try? -- Alex Bligh
On Thu, Sep 29, 2011 at 09:42:24PM +0100, Alex Bligh wrote:
Ondrej,
--On 29 September 2011 22:50:25 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
BTW, there is a similar (but mostly harmless) bug not related to NSSA - if an interface appears and there is a static route configured that goes through that iface, the static protocol receives the iface notification and generates the route, which is propagated to an ospf protocol before the iface notification, so gw is not found and the route is propagated without one.
That sounds like it might be what I'm seeing (see mail entitled "Directly connected interface redistribution problem" - yes I will get you the debug output you wanted, the test environment got rebuilt before I could get it), as what we're doing is redistributing static routes.
Do you have a fix I could try?
May be, but in my case the route is propagated, just without explicit forwarding address (so the propagating router is used as one, which is OK). I don't have a proper fix for that, it is a bit tricky problem. For a workaround it might help to reorder protocols in config file (OSPF before static, you can check in log file whether OSPF gets iface notifications before static). -- 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 our case this not harmless at all. We have searched what cause distribution problems when network link goes down and up. On our setup we distribute each computer as /32 route and on some cases when nic hang and reset it self or link goes down we lost /32 routes and it get fixed when we restart bird. 30.9.2011 9:00, Ondrej Zajicek kirjoitti:
On Thu, Sep 29, 2011 at 09:42:24PM +0100, Alex Bligh wrote:
Ondrej,
--On 29 September 2011 22:50:25 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
BTW, there is a similar (but mostly harmless) bug not related to NSSA - if an interface appears and there is a static route configured that goes through that iface, the static protocol receives the iface notification and generates the route, which is propagated to an ospf protocol before the iface notification, so gw is not found and the route is propagated without one. That sounds like it might be what I'm seeing (see mail entitled "Directly connected interface redistribution problem" - yes I will get you the debug output you wanted, the test environment got rebuilt before I could get it), as what we're doing is redistributing static routes.
Do you have a fix I could try? May be, but in my case the route is propagated, just without explicit forwarding address (so the propagating router is used as one, which is OK). I don't have a proper fix for that, it is a bit tricky problem. For a workaround it might help to reorder protocols in config file (OSPF before static, you can check in log file whether OSPF gets iface notifications before static).
-- F-Solutions Oy Tapio Haapala PL 7, 90571 Oulu GSM 040-0998371 Skype burner- IRC Burner@ircnet
participants (5)
-
Alex Bligh -
Alexander V. Chernikov -
Fedor Dikarev -
Ondrej Zajicek -
Tapio Haapala