OSPFv3: link-local address required on loopback interface?

Tore Anderson tore.anderson at redpill-linpro.com
Tue Aug 28 15:08:00 CEST 2012


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



More information about the Bird-users mailing list