On Wed, 2019-04-24 at 15:47 +0200, Ondrej Zajicek wrote: > On Wed, Apr 24, 2019 at 01:10:31PM +0000, Joakim Tjernlund wrote: > > On Tue, 2019-04-23 at 21:03 +0000, Joakim Tjernlund wrote: > > > 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 > > > > > > > I have a hard time understanding the code for section 12.4.1.1 Option 1 and > > Option 2: > > > > /* Now we will originate stub area if there is no primary */ > > if (net_lsa || > > (ifa->type == OSPF_IT_VLINK) || > > ((ifa->addr->flags & IA_PEER) && ! ifa->cf->stub) || > > configured_stubnet(oa, ifa->addr)) > > continue; > > Is the above always true for a ptp I/F? I am not clear over how IA_HOST, > > IA_PEER and ifa->cf->stub works. > > IA_HOST means /32, no peer address > IA_PEER means /32, and peer address > > ifa->cf->stub means explicitly configured stub/pasive mode.
OK, thanks. > > > > Also, important to agree if a /32 mask constitutes a subnet or not? > > /32 does not consistute subnet because it does not cover both local and > remote addresses. My view too. :) > > > > That would explain the below, there is no Option 1 > > Yes, we do not announce neighboring router's IP (Option 1) > OK, you are effectively considering your ptp I/F and the other side to be unnumbered always? I think that works for us ATM, just requires adding a lo0 host route to OSPF > (unless it is passive interface). Option 1 is about adding the peer IP address so a passive ptp I/F isn't strictly doing Option 1 but a route to itself. > > > /* Host or network stub entry */ > > if ((ifa->addr->flags & IA_HOST) || > > (ifa->state == OSPF_IS_LOOP) || > > (ifa->type == OSPF_IT_PTMP)) > > add_rt2_lsa_link(p, LSART_STUB, ipa_to_u32(ifa->addr->ip), > > 0xffffffff, 0); > > else > > add_rt2_lsa_link(p, LSART_STUB, > > ip4_to_u32(net4_prefix(&ifa->addr->prefix)), > > u32_mkmask(net4_pxlen(&ifa->addr->prefix)), ifa->cost); > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@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."
