BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

Ondrej Zajicek santiago at crfreenet.org
Tue Apr 23 19:33:18 CEST 2019


On Tue, Apr 23, 2019 at 12:40:04PM +0000, Joakim Tjernlund wrote:
> > I think the standard just does not consider the case of 'unnumbered'
> > link with both local and remote address but without subnet and assumes
> > 'real' unnumbered PtP link with no local IP address associated with
> > the iface.
> 
> There is always some local address, in linux you have to assign it to the I/F,
> but in others, like Cisco, you can assign an IP address to a dummy I/F and then
> tell unnumbered I/Fs to use the dummy I/Fs' IP address.
> There has to be some SRC IP address on pkgs sent by OSPF

Yes, but the way how the RFC is written it (IMHO) assumes the second case -
unnumbered ifaces using SRC IP from some dummy iface. Therefore stub
node is associated with the dummy iface and not with the unnumbered PtP iface.


> Since Linux always has an local IP adress it is not possible to deduce if the
> user intended the link to be unnumbered or not, unless one wants to add explicit
> config "unnumbered", it would be best to assume unnumbered I think.

I do not understand what you mean in this article. Linux could have active iface
without any IP address and it can be used for PtP link (with SRC IP from some
other iface), but it is not implemented in BIRD.

It is true that even a link with local /32 IP without specified remote peer could
be used for OSPF PtP link. BIRD in this case assumes it is a stub /32 and i am not
sure whether it could be configured as regular PtP. I did not realized before that
this is a relevant case for PtP link.


> Consider the use case with many /32 ptp links, all with the same local IP, there would
> be a lot of redundant host routes in the Router LSA. Better to let the user
> add an explicit stub network for all PtoP's if one needs it.

Well, that is solvable by not putting the same stub multiple times in the
Router LSA.

More debatable is a case like this:

eth0 10.0.0.1/24
eth1 10.0.0.1/32 peer 10.0.1.1/32

10.0.0.1 is already reachable by route for eth0 (either stub or network),
so it is technically not necessary to have it in the Router LSA as
a separate /32 stub. So it makes sense to me to have it configurable
with three values: yes, no, if-not-covered.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at 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."


More information about the Bird-users mailing list