BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA
Hello, I've been playing around with BIRD and OSPF for a while now and ran across an error I don't quite understand, while trying to get BIRD to advertise ip addresses on the loopback interface on a debian 10 server. # bird.conf: debug protocoll all; protocol device { scan time 10; }; protocol ospf v3 ospf_ip4 { ipv4 { export filter accept; import filter accept; import keep filtered; }; area 0.0.0.0 { interface "lo", "dummy*" { stub yes; }; }; }; # ip addr show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 10.50.0.1/32 scope global lo valid_lft forever preferred_lft forever inet6 fe80::1/128 scope link valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever Please note that loopback has a ipv6 link local address to get bird to recognize the interface. In theory, this should advertise 10.50.0.1/32 to other ospf routers, yet it doesn't and BIRD complains about LSAs with an invalid prefix This should advertise 10.50.0.1/32 to other routers and add the respective entries to the LSADB, yet bird starts complaing about an invalid LSA: "ospf_ip4: Invalid prefix in LSA (Type: 2001, Id: 0.0.0.0, Rt: 10.50.0.1)", I have attached the debug output of bird. Any help would be appreciated.
On Thu, Apr 11, 2019 at 08:38:44PM +0200, bauen1 wrote:
Hello,
I've been playing around with BIRD and OSPF for a while now and ran across an error I don't quite understand, while trying to get BIRD to advertise ip addresses on the loopback interface on a debian 10 server.
Hi It seems like a bug in handling of /32 IPv4 networks in OSPFv3 mode, i will look into that. -- 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."
On Thu, Apr 11, 2019 at 08:38:44PM +0200, bauen1 wrote:
Hello,
I've been playing around with BIRD and OSPF for a while now and ran across an error I don't quite understand, while trying to get BIRD to advertise ip addresses on the loopback interface on a debian 10 server.
Fixed by attached patch. -- 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."
On Fri, 2019-04-12 at 14:24 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Thu, Apr 11, 2019 at 08:38:44PM +0200, bauen1 wrote:
Hello,
I've been playing around with BIRD and OSPF for a while now and ran across an error I don't quite understand, while trying to get BIRD to advertise ip addresses on the loopback interface on a debian 10 server.
Fixed by attached patch.
Does this bug only apply to /32 addresses when running IPv4 over OSPFv3? Or is it also relevant for OSPFv2? Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) differently from OSPFv2?
-- 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."
On Mon, Apr 15, 2019 at 12:21:12PM +0000, Kenth Eriksson wrote:
On Fri, 2019-04-12 at 14:24 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Thu, Apr 11, 2019 at 08:38:44PM +0200, bauen1 wrote:
Hello,
I've been playing around with BIRD and OSPF for a while now and ran across an error I don't quite understand, while trying to get BIRD to advertise ip addresses on the loopback interface on a debian 10 server.
Fixed by attached patch.
Does this bug only apply to /32 addresses when running IPv4 over OSPFv3? Or is it also relevant for OSPFv2?
Only to IPv4 over OSPFv3.
Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) differently from OSPFv2?
Not in a significant way. -- 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."
On Mon, 2019-04-15 at 14:27 +0200, Ondrej Zajicek wrote:
On Mon, Apr 15, 2019 at 12:21:12PM +0000, Kenth Eriksson wrote:
On Fri, 2019-04-12 at 14:24 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Thu, Apr 11, 2019 at 08:38:44PM +0200, bauen1 wrote:
Hello,
I've been playing around with BIRD and OSPF for a while now and ran across an error I don't quite understand, while trying to get BIRD to advertise ip addresses on the loopback interface on a debian 10 server.
Fixed by attached patch.
Does this bug only apply to /32 addresses when running IPv4 over OSPFv3? Or is it also relevant for OSPFv2?
Only to IPv4 over OSPFv3.
Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) differently from OSPFv2?
Not in a significant way.
So a /32 shall be implicitly re-distributed in the OSPF area both for OSPFv2 and OSPFv3? I think that differs from how Quagga did it for unnumbered interfaces.
On Mon, Apr 15, 2019 at 12:56:24PM +0000, Kenth Eriksson wrote:
Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) differently from OSPFv2?
Not in a significant way.
So a /32 shall be implicitly re-distributed in the OSPF area both for OSPFv2 and OSPFv3? I think that differs from how Quagga did it for unnumbered interfaces.
Well, we are mixing two cases here: 1) Just /32 (or /128) stub addresses (with no peer) 2) 'Unnumbered' PtP addresses with /32 local and /32 peer address. The first case is always propagated in the OSPF area for both OSPFv2 and OSPFv3 as any other prefix. The second case is more complex. In OSPFv2, it always does not propagate /32 local addresses and it propagates /32 peer addresses only if configured as stub. In OSPFv3, this is not implemented and neither local /32 address nor peer /32 address are propagated (as Linux IPv6 does not have PtP addresses and we missed that when done OSPFv3-IPv4). But this we should fix and it should behave as in OSPFv2. Another issue is whether local /32 *should* be propagated for 'unnumbered' PtP links. We do not do that, but i think it should be configurable, and perhaps default yes in cases the local IP is not covered by range from other ifaces. You say it differs from Quagga, what is their behavior? -- 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."
On Thu, 2019-04-18 at 13:55 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Mon, Apr 15, 2019 at 12:56:24PM +0000, Kenth Eriksson wrote:
Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) differently from OSPFv2?
Not in a significant way.
So a /32 shall be implicitly re-distributed in the OSPF area both for OSPFv2 and OSPFv3? I think that differs from how Quagga did it for unnumbered interfaces.
Well, we are mixing two cases here:
1) Just /32 (or /128) stub addresses (with no peer)
2) 'Unnumbered' PtP addresses with /32 local and /32 peer address.
The first case is always propagated in the OSPF area for both OSPFv2 and OSPFv3 as any other prefix.
The second case is more complex. In OSPFv2, it always does not propagate /32 local addresses and it propagates /32 peer addresses only if configured as stub. In OSPFv3, this is not implemented and neither local /32 address nor peer /32 address are propagated (as Linux IPv6 does not have PtP addresses and we missed that when done OSPFv3-IPv4). But this we should fix and it should behave as in OSPFv2.
Does the description you give here comply to the intent in section 12.4.1.1 of RFC2328? The following statement of the RFC makes the intent a bit unclear to me; "...a Type 3 link (stub network) should be added."
Another issue is whether local /32 *should* be propagated for 'unnumbered' PtP links. We do not do that, but i think it should be configurable, and perhaps default yes in cases the local IP is not covered by range from other ifaces.
Configureable seems like a sensible thing to me. The default should be what the standard suggests.
You say it differs from Quagga, what is their behavior?
I'm not sure there is a difference after you explained that unnumbered /32 with peer was treated different compared to /32 without peer. But when I looked into the frr git repo, I can see that unnumbered interface support was added in in git sha 525c183906c47c491611f294db218d53a561a3b9. Prior to that commit I think quagga always re-distributed unnumbered interfaces as well.
-- 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."
On Tue, Apr 23, 2019 at 10:28:46AM +0000, Kenth Eriksson wrote:
The second case is more complex. In OSPFv2, it always does not propagate /32 local addresses and it propagates /32 peer addresses only if configured as stub. In OSPFv3, this is not implemented and neither local /32 address nor peer /32 address are propagated (as Linux IPv6 does not have PtP addresses and we missed that when done OSPFv3-IPv4). But this we should fix and it should behave as in OSPFv2.
Does the description you give here comply to the intent in section 12.4.1.1 of RFC2328? The following statement of the RFC makes the intent a bit unclear to me; "...a Type 3 link (stub network) should be added."
The section 12.4.1.1 for 'unnumbered' case (Option 1) describes handling of *peer* IP address, it is silent about handling of *local* IP address.
Another issue is whether local /32 *should* be propagated for 'unnumbered' PtP links. We do not do that, but i think it should be configurable, and perhaps default yes in cases the local IP is not covered by range from other ifaces.
Configureable seems like a sensible thing to me. The default should be what the standard suggests.
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. -- 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."
On Tue, 2019-04-23 at 14:09 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Tue, Apr 23, 2019 at 10:28:46AM +0000, Kenth Eriksson wrote:
The second case is more complex. In OSPFv2, it always does not propagate /32 local addresses and it propagates /32 peer addresses only if configured as stub. In OSPFv3, this is not implemented and neither local /32 address nor peer /32 address are propagated (as Linux IPv6 does not have PtP addresses and we missed that when done OSPFv3-IPv4). But this we should fix and it should behave as in OSPFv2.
Does the description you give here comply to the intent in section 12.4.1.1 of RFC2328? The following statement of the RFC makes the intent a bit unclear to me; "...a Type 3 link (stub network) should be added."
The section 12.4.1.1 for 'unnumbered' case (Option 1) describes handling of *peer* IP address, it is silent about handling of *local* IP address.
Another issue is whether local /32 *should* be propagated for 'unnumbered' PtP links. We do not do that, but i think it should be configurable, and perhaps default yes in cases the local IP is not covered by range from other ifaces.
Configureable seems like a sensible thing to me. The default should be what the standard suggests.
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 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. 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.
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@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."
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
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. Also, important to agree if a /32 mask constitutes a subnet or not? That would explain the below, there is no Option 1 /* 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);
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.
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.
That would explain the below, there is no Option 1
Yes, we do not announce neighboring router's IP (Option 1) (unless it is passive interface).
/* 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: 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."
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: 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."
On Wed, 2019-04-24 at 16:16 +0200, Joakim Tjernlund wrote:
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.
Just to be clear, I suspect you don't do Option 2 either for non /32 PtP links? The ifa->addr->flags & IA_PEER is true for all PtP links, right ? Weather to do Option 1 could be a config option if you want to complete, I don't need it though. Jocke
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);
participants (4)
-
bauen1 -
Joakim Tjernlund -
Kenth Eriksson -
Ondrej Zajicek