OSPFv3: link-local address required on loopback interface?
I've run across a rather weird behaviour in BIRD 1.3.8 regarding the interaction between address(es) on the loopback interface and the OSPFv3 protocol. It seems that if there's no link-local address on the interface, BIRD fails to run OSPF in stub mode on it: $ birdc6 show interfaces BIRD 1.3.8 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 ::1/128 (Primary, scope host) 2001:db8:1::3/128 (Unselected, scope univ) [...] $ birdc6 show ospf interface \"lo\" BIRD 1.3.8 ready. ospf1: $ ip -6 address add fe80::/64 scope link dev lo $ birdc6 show ospf interface \"lo\" BIRD 1.3.8 ready. ospf1: Interface lo (IID 0) Type: nbma Area: 47.4.0.0 (788791296) State: waiting (stub) Priority: 1 Cost: 10 Hello timer: 10 Poll timer: 20 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designed router (ID): 0.0.0.0 Designed router (IP): :: Backup designed router (ID): 0.0.0.0 Backup designed router (IP): :: $ birdc6 show interfaces BIRD 1.3.8 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 2001:db8:1::3/128 (Primary, scope univ) ::1/128 (Unselected, scope host) fe80::/64 (Unselected, scope link) [...] Question: What does «Ignored» imply here? Also, why did the «Primary» address change as a result of fe80:: being added? In any case, this means that without a link-local address being manually added to the loopback interface, the primary address of the router won't be reachable from the rest of the network, in turn causing problems for monitoring and possibly other protocols like iBGP. This must be a bug, right? Being able to import the loopback interface of a router as a stub network into the IGP is pretty fundamental functionality. Also, link-local addresses aren't typically seen on loopback interfaces, so expecting them to be there doesn't make much sense to me. My configuration is as follows: protocol device { scan time 10; } protocol kernel { scan time 10; learn; export all; import all; } protocol ospf { area 47.4.0.0 { interface "bond0" { type broadcast; }; interface "*" { stub yes; }; }; } -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On Tue, Aug 28, 2012 at 03:08:00PM +0200, Tore Anderson wrote:
I've run across a rather weird behaviour in BIRD 1.3.8 regarding the interaction between address(es) on the loopback interface and the OSPFv3 protocol. It seems that if there's no link-local address on the interface, BIRD fails to run OSPF in stub mode on it: ...
Question: What does ?Ignored? imply here?
That it is loopback and should not be used for active ifaces. But stub ifaces should be OK.
Also, why did the ?Primary? address change as a result of fe80:: being added?
This is a bug in primary address selection.
In any case, this means that without a link-local address being manually added to the loopback interface, the primary address of the router won't be reachable from the rest of the network, in turn causing problems for monitoring and possibly other protocols like iBGP.
This must be a bug, right? Being able to import the loopback interface of a router as a stub network into the IGP is pretty fundamental functionality. Also, link-local addresses aren't typically seen on loopback interfaces, so expecting them to be there doesn't make much sense to me.
OSPFv3 requires link-local address on iface to work, so there is just a missing exception for stub ifaces. Also note that some people suggest to use dummy iface instead of loopback iface for that purpose. But i don't know any valid reason why. Perhaps just to workaround similar issues in other software. -- 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
Also, why did the ?Primary? address change as a result of fe80:: being added?
This is a bug in primary address selection.
[...]
OSPFv3 requires link-local address on iface to work, so there is just a missing exception for stub ifaces.
Aha, that makes sense. I'll be happy to test any patches. ;-) I was wondering, by the way, is there an issue tracker or something similar for BIRD, where I can file bugs and/or feature enhancement requests? Or is this mailing list basically it?
Also note that some people suggest to use dummy iface instead of loopback iface for that purpose. But i don't know any valid reason why. Perhaps just to workaround similar issues in other software.
I suppose that too will work. For what it's worth, though, I've not had any problems assigning the primary address of a router to the loopback interface until now; as far as I know, it's actually the recommended best practise for most router implementations, at least for Cisco IOS, JUNOS, Quagga, Vyatta, and so on. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
On Wed, Aug 29, 2012 at 08:00:34AM +0200, Tore Anderson wrote:
* Ondrej Zajicek
Also, why did the ?Primary? address change as a result of fe80:: being added?
This is a bug in primary address selection.
[...]
OSPFv3 requires link-local address on iface to work, so there is just a missing exception for stub ifaces.
Aha, that makes sense. I'll be happy to test any patches. ;-)
I was wondering, by the way, is there an issue tracker or something similar for BIRD, where I can file bugs and/or feature enhancement requests? Or is this mailing list basically it?
Yes, this mailing list should be the primary channel for bug reporting. -- 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."
participants (2)
-
Ondrej Zajicek -
Tore Anderson