On Tue, 2019-04-23 at 19:33 +0200, Ondrej Zajicek wrote: > > 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
yes, the second case, agreed. > node is associated with the dummy iface and not with the unnumbered PtP iface. No, this is a true unnumbered I/F(it has no local IP address) and will not generate any stub route. > > > > 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. I expressed myself badly, I meant if one want to have control over what SRC ip is used, you need to have it on the local I/F. Maybe there is a way to do that these days differently but I don't think any PtoP impl. on Linux uses that. > > 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. This case is as close one gets to a true unnumbered I/F in Linux I think and pppd supports such links. I think should treat /32 links as unnumbered even if there is an remote IP address or make it configurable. > > > 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. Maybe but since it is the remote ip one puts here you will only save "space" when you have multiple ptop links between the same two routers. > > 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. Yes, this is what I was getting at too. Maybe have a conf option "unnumbered" to treat eth1 as a "true" unnumbred I/F(no stub network). Quietion is, what should be default? What is default in current 2.0 Bird? Jocke