ospf ptp link sending unicast packets instead of multicast; peer address config not required
Hi, I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again. I’m seeing some issues with ospf adj over ptpnumbered/unnumbered interface. 1. Forp2p connections, ospf should be sending only multicast packets toallospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, theIP destination is always set to the address AllSPFRouters”) 2. Forptp over unnumbered interface, bird requires peer address configuration whichis not required from the ospf perspective. Because bird is using peer addressand sending unicast packets, bird cannot form multiple ospf adj over ptpunnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch thataddresses the issues. Relaxed the source ip address validation for ptp link inpacket.c for now. More validation can be added to make it complete. Thanks and Regards,Senthil
On Thu, 2021-05-06 at 17:09 +0000, Senthil Kumar Nagappan wrote:
Hi,
I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again.
I’m seeing some issues with ospf adj over ptp numbered/unnumbered interface.
1. For p2p connections, ospf should be sending only multicast packets to allospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters”)
Agreed, I recall fixing the same for Quagga long time ago.
2. For ptp over unnumbered interface, bird requires peer address configuration which is not required from the ospf perspective. Because bird is using peer address and sending unicast packets, bird cannot form multiple ospf adj over ptp unnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch that addresses the issues. Relaxed the source ip address validation for ptp link in packet.c for now. More validation can be added to make it complete.
I don't quite understand what you are saying here, can you elaborate? Jocke
On Thu, 2021-05-06 at 20:30 +0200, Joakim Tjernlund wrote:
On Thu, 2021-05-06 at 17:09 +0000, Senthil Kumar Nagappan wrote:
Hi,
I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again.
I’m seeing some issues with ospf adj over ptp numbered/unnumbered interface.
1. For p2p connections, ospf should be sending only multicast packets to allospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters”)
Agreed, I recall fixing the same for Quagga long time ago.
2. For ptp over unnumbered interface, bird requires peer address configuration which is not required from the ospf perspective. Because bird is using peer address and sending unicast packets, bird cannot form multiple ospf adj over ptp unnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch that addresses the issues. Relaxed the source ip address validation for ptp link in packet.c for now. More validation can be added to make it complete.
I don't quite understand what you are saying here, can you elaborate?
One thing I recall, BIRD OSPF seems to always require dest IP address for its routes. For a PtoP I/F this is optional/not needed so I guess this is a bug in BIRD. Possibly because of bug 1) Jocke
Hi Joakim, Thanks for your response. Will try to elaborate point2 with sample config. 1. Config at Router R1 lo interfaceinterface loopback lo has ip addr 100.100.100.125 eth1for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth1 eth2for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth2 2. Config at Router R2Its identical to R1 config except for the loopback ip which is 100.100.100.126 and the correspondingpeer address config for eth1 and eth2 3. Enable ospf on eth1 and eth2 at R1 and R2 4. Only one of the ospf adj will become FULL either over eth1 or eth2 and not both 5. Since the peer address configurations adds a route to other end loopback address and since thedb packets are sent as unicast, route lookup happens and db packets wont be sent out from one of the links. 6. one ospf adj will be FULL and the other one will stay at EXSTART 7. if we use different peer address for each interface then it will work. Thanks and Regards,Senthil On Friday, May 7, 2021, 12:33:11 AM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote: On Thu, 2021-05-06 at 20:30 +0200, Joakim Tjernlund wrote:
On Thu, 2021-05-06 at 17:09 +0000, Senthil Kumar Nagappan wrote:
Hi,
I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again.
I’m seeing some issues with ospf adj over ptp numbered/unnumbered interface.
1. For p2p connections, ospf should be sending only multicast packets to allospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters”)
Agreed, I recall fixing the same for Quagga long time ago.
2. For ptp over unnumbered interface, bird requires peer address configuration which is not required from the ospf perspective. Because bird is using peer address and sending unicast packets, bird cannot form multiple ospf adj over ptp unnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch that addresses the issues. Relaxed the source ip address validation for ptp link in packet.c for now. More validation can be added to make it complete.
I don't quite understand what you are saying here, can you elaborate?
One thing I recall, BIRD OSPF seems to always require dest IP address for its routes. For a PtoP I/F this is optional/not needed so I guess this is a bug in BIRD. Possibly because of bug 1) Jocke
On Fri, 2021-05-07 at 04:53 +0000, Senthil Kumar Nagappan wrote:
Hi Joakim,
Thanks for your response.
Will try to elaborate point2 with sample config.
1. Config at Router R1
lo interface interface loopback lo has ip addr 100.100.100.125
eth1 for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth1
eth2 for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth2
2. Config at Router R2 Its identical to R1 config except for the loopback ip which is 100.100.100.126 and the corresponding peer address config for eth1 and eth2
I see, this makes sense. I wonder if this problem would affect true PtoP links as well? The only thing left then is when you have true PtoP links one does not need a remote address, that is another issue though, maybe Ondrej can comment?
3. Enable ospf on eth1 and eth2 at R1 and R2
4. Only one of the ospf adj will become FULL either over eth1 or eth2 and not both
5. Since the peer address configurations adds a route to other end loopback address and since the db packets are sent as unicast, route lookup happens and db packets wont be sent out from one of the links.
6. one ospf adj will be FULL and the other one will stay at EXSTART
7. if we use different peer address for each interface then it will work.
Thanks and Regards, Senthil
On Friday, May 7, 2021, 12:33:11 AM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote:
On Thu, 2021-05-06 at 20:30 +0200, Joakim Tjernlund wrote:
On Thu, 2021-05-06 at 17:09 +0000, Senthil Kumar Nagappan wrote:
Hi,
I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again.
I’m seeing some issues with ospf adj over ptp numbered/unnumbered interface.
1. For p2p connections, ospf should be sending only multicast packets to allospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters”)
Agreed, I recall fixing the same for Quagga long time ago.
2. For ptp over unnumbered interface, bird requires peer address configuration which is not required from the ospf perspective. Because bird is using peer address and sending unicast packets, bird cannot form multiple ospf adj over ptp unnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch that addresses the issues. Relaxed the source ip address validation for ptp link in packet.c for now. More validation can be added to make it complete.
I don't quite understand what you are saying here, can you elaborate?
One thing I recall, BIRD OSPF seems to always require dest IP address for its routes. For a PtoP I/F this is optional/not needed so I guess this is a bug in BIRD. Possibly because of bug 1)
Jocke
On Fri, May 07, 2021 at 04:53:44AM +0000, Senthil Kumar Nagappan wrote:
Hi Joakim, Thanks for your response. Will try to elaborate point2 with sample config. 1. Config at Router R1 lo interfaceinterface loopback lo has ip addr 100.100.100.125 eth1for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth1 eth2for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth2 2. Config at Router R2Its identical to R1 config except for the loopback ip which is 100.100.100.126 and the correspondingpeer address config for eth1 and eth2
3. Enable ospf on eth1 and eth2 at R1 and R2 4. Only one of the ospf adj will become FULL either over eth1 or eth2 and not both 5. Since the peer address configurations adds a route to other end loopback address and since thedb packets are sent as unicast, route lookup happens and db packets wont be sent out from one of the links.
I do not think that should be true (at least on Linux). OSPF sockets are bound to specific interface using SO_BINDTODEVICE and use SO_DONTROUTE to avoid route lookups, so even unicast packets should be sent to specific interface. If that really happens, that is worth investigating. What is your OS and BIRD version? Did you verify that using tcpdump or similar tool? -- 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, 2021-05-07 at 13:09 +0200, Ondrej Zajicek wrote:
On Fri, May 07, 2021 at 04:53:44AM +0000, Senthil Kumar Nagappan wrote:
Hi Joakim, Thanks for your response. Will try to elaborate point2 with sample config. 1. Config at Router R1 lo interfaceinterface loopback lo has ip addr 100.100.100.125 eth1for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth1 eth2for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth2 2. Config at Router R2Its identical to R1 config except for the loopback ip which is 100.100.100.126 and the correspondingpeer address config for eth1 and eth2
3. Enable ospf on eth1 and eth2 at R1 and R2 4. Only one of the ospf adj will become FULL either over eth1 or eth2 and not both 5. Since the peer address configurations adds a route to other end loopback address and since thedb packets are sent as unicast, route lookup happens and db packets wont be sent out from one of the links.
I do not think that should be true (at least on Linux). OSPF sockets are bound to specific interface using SO_BINDTODEVICE and use SO_DONTROUTE to avoid route lookups, so even unicast packets should be sent to specific interface. If that really happens, that is worth investigating. What is your OS and BIRD version? Did you verify that using tcpdump or similar tool?
That may be so, but I still think that the issue reported in 1) is valid bug, don't you? Jocke
On Fri, May 07, 2021 at 11:14:27AM +0000, Joakim Tjernlund wrote:
On Fri, 2021-05-07 at 13:09 +0200, Ondrej Zajicek wrote:
On Fri, May 07, 2021 at 04:53:44AM +0000, Senthil Kumar Nagappan wrote:
Hi Joakim, Thanks for your response. Will try to elaborate point2 with sample config. 1. Config at Router R1 lo interfaceinterface loopback lo has ip addr 100.100.100.125 eth1for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth1 eth2for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth2 2. Config at Router R2Its identical to R1 config except for the loopback ip which is 100.100.100.126 and the correspondingpeer address config for eth1 and eth2
3. Enable ospf on eth1 and eth2 at R1 and R2 4. Only one of the ospf adj will become FULL either over eth1 or eth2 and not both 5. Since the peer address configurations adds a route to other end loopback address and since thedb packets are sent as unicast, route lookup happens and db packets wont be sent out from one of the links.
I do not think that should be true (at least on Linux). OSPF sockets are bound to specific interface using SO_BINDTODEVICE and use SO_DONTROUTE to avoid route lookups, so even unicast packets should be sent to specific interface. If that really happens, that is worth investigating. What is your OS and BIRD version? Did you verify that using tcpdump or similar tool?
That may be so, but I still think that the issue reported in 1) is valid bug, don't you?
Yes, i agree. Just think that this issue is worth investigating independently and not just avoiding that by fixing 1). -- 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."
Hi Ondrej, using latest bird cloned a week back and using montavista linux.yes, i verified using tcpdump, in one of the interface capture where the adj is stuck in exstart state, only hello packets and unresolved arp requests are seen. (please see the attached eth2.pcap) and in the other eth1.pcap adj is FULL and you can notice db pkts are unicast.Using a proprietary hw/sim and don't have a general purpose linux setup to try. forget about the route lookup, for the configuration that i mentioned, only one of adj is up and other is down. why? Do you think this configuration will work in the standard linux system, were both the adj comes up fine? Thanks and Regards,Senthil On Friday, May 7, 2021, 04:39:32 PM GMT+5:30, Ondrej Zajicek <santiago@crfreenet.org> wrote: On Fri, May 07, 2021 at 04:53:44AM +0000, Senthil Kumar Nagappan wrote:
Hi Joakim, Thanks for your response. Will try to elaborate point2 with sample config. 1. Config at Router R1 lo interfaceinterface loopback lo has ip addr 100.100.100.125 eth1for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth1 eth2for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer addressip addr add 100.100.100.125 peer 100.100.100.126 dev eth2 2. Config at Router R2Its identical to R1 config except for the loopback ip which is 100.100.100.126 and the correspondingpeer address config for eth1 and eth2
3. Enable ospf on eth1 and eth2 at R1 and R2 4. Only one of the ospf adj will become FULL either over eth1 or eth2 and not both 5. Since the peer address configurations adds a route to other end loopback address and since thedb packets are sent as unicast, route lookup happens and db packets wont be sent out from one of the links.
I do not think that should be true (at least on Linux). OSPF sockets are bound to specific interface using SO_BINDTODEVICE and use SO_DONTROUTE to avoid route lookups, so even unicast packets should be sent to specific interface. If that really happens, that is worth investigating. What is your OS and BIRD version? Did you verify that using tcpdump or similar tool? -- 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, May 07, 2021 at 01:46:18PM +0000, Senthil Kumar Nagappan wrote:
Hi Ondrej, using latest bird cloned a week back and using montavista linux.yes, i verified using tcpdump, in one of the interface capture where the adj is stuck in exstart state, only hello packets and unresolved arp requests are seen. (please see the attached eth2.pcap) and in the other eth1.pcap adj is FULL and you can notice db pkts are unicast.Using a proprietary hw/sim and don't have a general purpose linux setup to try.
forget about the route lookup, for the configuration that i mentioned, only one of adj is up and other is down. why? Do you think this configuration will work in the standard linux system, were both the adj comes up fine?
Hi Just tested it in the standard linux sytem and it worked fine. DBdes packets for each adjacency are exchanged on each iface. So perhaps that is really something strange in your setup. -- 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, 2021-05-07 at 04:53 +0000, Senthil Kumar Nagappan wrote:
Hi Joakim,
Thanks for your response.
Will try to elaborate point2 with sample config.
1. Config at Router R1
lo interface interface loopback lo has ip addr 100.100.100.125
eth1 for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth1
eth2 for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth2
Just to be clear, are those eth I/F directly connected via a cable or is there a switch in between? Jocke
Yes, there is a switch in between. On Friday, May 7, 2021, 06:17:28 PM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote: On Fri, 2021-05-07 at 04:53 +0000, Senthil Kumar Nagappan wrote:
Hi Joakim,
Thanks for your response.
Will try to elaborate point2 with sample config.
1. Config at Router R1
lo interface interface loopback lo has ip addr 100.100.100.125
eth1 for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth1
eth2 for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth2
Just to be clear, are those eth I/F directly connected via a cable or is there a switch in between? Jocke
On Fri, 2021-05-07 at 13:50 +0000, Senthil Kumar Nagappan wrote:
Yes, there is a switch in between.
hmm, I am not familiar with eth PtoP I/Fs but if you have a switch then the different links can see each others pkgs (broadcast etc.). Not sure that is a valid use case? Jocke
On Friday, May 7, 2021, 06:17:28 PM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote:
On Fri, 2021-05-07 at 04:53 +0000, Senthil Kumar Nagappan wrote:
Hi Joakim,
Thanks for your response.
Will try to elaborate point2 with sample config.
1. Config at Router R1
lo interface interface loopback lo has ip addr 100.100.100.125
eth1 for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth1
eth2 for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth2
Just to be clear, are those eth I/F directly connected via a cable or is there a switch in between?
Jocke
ptp can be physical or pseudo/virtual connection, it could be over optical/OTN/ethernet/serial/... but these 2 endpoints in the p2p link will see/receive only the packets(all of unicast/multicast/broadcast) originated by the other end of the p2p connection. On Friday, May 7, 2021, 08:20:20 PM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote: On Fri, 2021-05-07 at 13:50 +0000, Senthil Kumar Nagappan wrote:
Yes, there is a switch in between.
hmm, I am not familiar with eth PtoP I/Fs but if you have a switch then the different links can see each others pkgs (broadcast etc.). Not sure that is a valid use case? Jocke
On Friday, May 7, 2021, 06:17:28 PM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote:
On Fri, 2021-05-07 at 04:53 +0000, Senthil Kumar Nagappan wrote:
Hi Joakim,
Thanks for your response.
Will try to elaborate point2 with sample config.
1. Config at Router R1
lo interface interface loopback lo has ip addr 100.100.100.125
eth1 for unnumbered borrowing the lo address for eth1 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth1
eth2 for unnumbered borrowing the lo address for eth2 and 100.100.100.126 is the peer address ip addr add 100.100.100.125 peer 100.100.100.126 dev eth2
Just to be clear, are those eth I/F directly connected via a cable or is there a switch in between?
Jocke
On Thu, May 06, 2021 at 05:09:53PM +0000, Senthil Kumar Nagappan wrote:
Hi, I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again. I’m seeing some issues with ospf adj over ptpnumbered/unnumbered interface. 1. Forp2p connections, ospf should be sending only multicast packets toallospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, theIP destination is always set to the address AllSPFRouters”)
Hi Thanks for noticing this RFC, that is good argument to change this.
2. Forptp over unnumbered interface, bird requires peer address configuration whichis not required from the ospf perspective. Because bird is using peer addressand sending unicast packets, bird cannot form multiple ospf adj over ptpunnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch thataddresses the issues. Relaxed the source ip address validation for ptp link inpacket.c for now. More validation can be added to make it complete. Thanks and Regards,Senthil
This is more complicated issue. BIRD OSPF implementation does not really enumerate physical interfaces, but address ranges assigned to them. Therefore, one could run two different address ranges on an iface and it will behave as two different OSPF ifaces (two broadcast network with different prefixes, two PtP links, or even one broadcast network and one PtP link). This is very flexible (these virtual OSPF ifaces can even have different configuration), but it also leads to the result that physical interface without address is not an OSPF interface, so even unnumbered ptp interfaces require peer address configuration to define OSFP interface. Also note that PtP interfaces need not be physical PtP interfaces, most often it is just ethernet configured as PtP. It is hard to reconcile existing model with true unnumbered ifaces (considering that say IP addresses can appear dynamically so we should not claim that iface without address is ptp iface). I think that long term solution is to require that all virtual OSPF ifaces on one physical iface are of the same type (broadcast vs ptp), but it would require significant redesign of OSPF iface enumerating code and break some backwards compatibility in corner cases. Note that this second issue is unrelated to the first one - dst addressess of unicast packets are taken from neighbor structure, which is initialized from src address of neighbor's Hello packets. -- 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, 2021-05-06 at 17:09 +0000, Senthil Kumar Nagappan wrote:
Hi,
I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again.
I’m seeing some issues with ospf adj over ptp numbered/unnumbered interface.
1. For p2p connections, ospf should be sending only multicast packets to allospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters”) 2. For ptp over unnumbered interface, bird requires peer address configuration which is not required from the ospf perspective. Because bird is using peer address and sending unicast packets, bird cannot form multiple ospf adj over ptp unnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch that addresses the issues. Relaxed the source ip address validation for ptp link in packet.c for now. More validation can be added to make it complete.
Thanks and Regards, Senthil
Hi Senthil I took a closer look at your hack/patch ... You seem to miss correcting a few ospf_send_to() call sites. I wonder in its not better to override the dst addr inside ospf_send_to() instead? Also, the mcast changes in packet.c looks incomplete, there is IPv6 and and area == 0 further down to consider. Jocke
Hi Jocke, yes i missed to take care of the ospfv3/ipv6 cases wherever im sending using allospfrouters as src ip.your are right, mcast changes in packet.c is mostly hack since im not comfortable with the bird code since i have only 1 week of bird code experience.reason i did not change inside ospf_send_to() is,since dst address is one of the parameter to the function and i don't want to override inside it. In Hello.c, ospf_send_hello they do some what similar, checking different interface types before they call ospf_send_to() Thanks and Regards,Senthil On Friday, May 7, 2021, 06:14:16 PM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote: On Thu, 2021-05-06 at 17:09 +0000, Senthil Kumar Nagappan wrote:
Hi,
I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again.
I’m seeing some issues with ospf adj over ptp numbered/unnumbered interface.
1. For p2p connections, ospf should be sending only multicast packets to allospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters”) 2. For ptp over unnumbered interface, bird requires peer address configuration which is not required from the ospf perspective. Because bird is using peer address and sending unicast packets, bird cannot form multiple ospf adj over ptp unnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch that addresses the issues. Relaxed the source ip address validation for ptp link in packet.c for now. More validation can be added to make it complete.
Thanks and Regards, Senthil
Hi Senthil I took a closer look at your hack/patch ... You seem to miss correcting a few ospf_send_to() call sites. I wonder in its not better to override the dst addr inside ospf_send_to() instead? Also, the mcast changes in packet.c looks incomplete, there is IPv6 and and area == 0 further down to consider. Jocke
On Fri, 2021-05-07 at 14:03 +0000, Senthil Kumar Nagappan wrote:
Hi Jocke,
yes i missed to take care of the ospfv3/ipv6 cases wherever im sending using allospfrouters as src ip. your are right, mcast changes in packet.c is mostly hack since im not comfortable with the bird code since i have only 1 week of bird code experience. reason i did not change inside ospf_send_to() is,since dst address is one of the parameter to the function and i don't want to override inside it. In Hello.c, ospf_send_hello they do some what similar, checking different interface types before they call ospf_send_to()
Ondrej, what is your preference? Perhaps you want to do the impl. yourself? Jocke
On Sat, 2021-05-08 at 17:45 +0200, Joakim Tjernlund wrote:
On Fri, 2021-05-07 at 14:03 +0000, Senthil Kumar Nagappan wrote:
Hi Jocke,
yes i missed to take care of the ospfv3/ipv6 cases wherever im sending using allospfrouters as src ip. your are right, mcast changes in packet.c is mostly hack since im not comfortable with the bird code since i have only 1 week of bird code experience. reason i did not change inside ospf_send_to() is,since dst address is one of the parameter to the function and i don't want to override inside it. In Hello.c, ospf_send_hello they do some what similar, checking different interface types before they call ospf_send_to()
Ondrej, what is your preference? Perhaps you want to do the impl. yourself?
Jocke
Meanwhile I did this: --- a/proto/ospf/packet.c +++ b/proto/ospf/packet.c @@ -415,7 +415,7 @@ ospf_rx_hook(sock *sk, uint len) * that (src_local || dst_local), therefore we are eliminating all * such cases. */ - if (dst_mcast && !src_local) + if (ifa->type != OSPF_IT_PTP && dst_mcast && !src_local) return 1; if (!dst_mcast && !dst_local) return 1; @@ -430,7 +430,7 @@ ospf_rx_hook(sock *sk, uint len) * RFC 5340 says that local (non-vlink) packets use * link-local src address, but does not enforce it. Strange. */ - if (dst_mcast && !src_local) + if (ifa->type != OSPF_IT_PTP && dst_mcast && !src_local) LOG_PKT_WARN("Multicast packet received from non-link-local %I via %s", sk->faddr, ifa->ifname); } @@ -654,6 +654,12 @@ ospf_send_to(struct ospf_iface *ifa, ip_addr dst) struct ospf_packet *pkt = (struct ospf_packet *) sk->tbuf; uint plen = ntohs(pkt->length); + /* RFC : On physical point-to-point networks, the IP destination + * is always set to the address AllSPFRouters. + */ + if (ifa->type == OSPF_IT_PTP) + dst = ifa->all_routers; + if (ospf_is_v2(ifa->oa->po)) ospf_pkt_finalize2(ifa, pkt, &plen); else In your patch you also have: --- a/proto/ospf/iface.c +++ b/proto/ospf/iface.c @@ -535,6 +535,9 @@ ospf_iface_stubby(struct ospf_iface_patt *ip, struct ifa *addr) if (ip->type == OSPF_IT_VLINK) return 0; + if (ip->type == OSPF_IT_PTP) + return 0; + What is that about? Is it unrelated to AllSPFRouters change? Jocke
For unnumbered ptp interface, if it had borrowed an address with /32, then bird currently wont send hello packets and wont try to form adj. On Saturday, May 8, 2021, 09:33:37 PM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote: On Sat, 2021-05-08 at 17:45 +0200, Joakim Tjernlund wrote:
On Fri, 2021-05-07 at 14:03 +0000, Senthil Kumar Nagappan wrote:
Hi Jocke,
yes i missed to take care of the ospfv3/ipv6 cases wherever im sending using allospfrouters as src ip. your are right, mcast changes in packet.c is mostly hack since im not comfortable with the bird code since i have only 1 week of bird code experience. reason i did not change inside ospf_send_to() is,since dst address is one of the parameter to the function and i don't want to override inside it. In Hello.c, ospf_send_hello they do some what similar, checking different interface types before they call ospf_send_to()
Ondrej, what is your preference? Perhaps you want to do the impl. yourself?
Jocke
Meanwhile I did this: --- a/proto/ospf/packet.c +++ b/proto/ospf/packet.c @@ -415,7 +415,7 @@ ospf_rx_hook(sock *sk, uint len) * that (src_local || dst_local), therefore we are eliminating all * such cases. */ - if (dst_mcast && !src_local) + if (ifa->type != OSPF_IT_PTP && dst_mcast && !src_local) return 1; if (!dst_mcast && !dst_local) return 1; @@ -430,7 +430,7 @@ ospf_rx_hook(sock *sk, uint len) * RFC 5340 says that local (non-vlink) packets use * link-local src address, but does not enforce it. Strange. */ - if (dst_mcast && !src_local) + if (ifa->type != OSPF_IT_PTP && dst_mcast && !src_local) LOG_PKT_WARN("Multicast packet received from non-link-local %I via %s", sk->faddr, ifa->ifname); } @@ -654,6 +654,12 @@ ospf_send_to(struct ospf_iface *ifa, ip_addr dst) struct ospf_packet *pkt = (struct ospf_packet *) sk->tbuf; uint plen = ntohs(pkt->length); + /* RFC : On physical point-to-point networks, the IP destination + * is always set to the address AllSPFRouters. + */ + if (ifa->type == OSPF_IT_PTP) + dst = ifa->all_routers; + if (ospf_is_v2(ifa->oa->po)) ospf_pkt_finalize2(ifa, pkt, &plen); else In your patch you also have: --- a/proto/ospf/iface.c +++ b/proto/ospf/iface.c @@ -535,6 +535,9 @@ ospf_iface_stubby(struct ospf_iface_patt *ip, struct ifa *addr) if (ip->type == OSPF_IT_VLINK) return 0; + if (ip->type == OSPF_IT_PTP) + return 0; + What is that about? Is it unrelated to AllSPFRouters change? Jocke
we use borrowed /32 addr on our PtoP(pppoe) and that work for us. ________________________________________ From: Senthil Kumar Nagappan <sknagappan@yahoo.com> Sent: 08 May 2021 18:26 To: bird-users@network.cz; Joakim Tjernlund Subject: Re: ospf ptp link sending unicast packets instead of multicast; peer address config not required For unnumbered ptp interface, if it had borrowed an address with /32, then bird currently wont send hello packets and wont try to form adj. On Saturday, May 8, 2021, 09:33:37 PM GMT+5:30, Joakim Tjernlund <joakim.tjernlund@infinera.com> wrote:
On Sat, May 08, 2021 at 04:03:34PM +0000, Joakim Tjernlund wrote:
Meanwhile I did this: --- a/proto/ospf/packet.c +++ b/proto/ospf/packet.c @@ -415,7 +415,7 @@ ospf_rx_hook(sock *sk, uint len) * that (src_local || dst_local), therefore we are eliminating all * such cases. */ - if (dst_mcast && !src_local) + if (ifa->type != OSPF_IT_PTP && dst_mcast && !src_local) return 1;
Hi This check should be done in a different way. If i have iface eth0 that has two addresses: 10.0.0.1 peer 10.0.1.1 10.0.0.1 peer 10.0.2.1 Then BIRD would make two separate virtual OSPF PtP ifaces and the check above ensures that Hello packets from 10.0.1.1 does not appear on second iface and ones from 10.0.2.1 on the first iface. If we want to add support for PtP iface with host address without configured peer address, then this check should not apply (so we would accept any peer), but not for all PtP ifaces.
@@ -430,7 +430,7 @@ ospf_rx_hook(sock *sk, uint len) * RFC 5340 says that local (non-vlink) packets use * link-local src address, but does not enforce it. Strange. */ - if (dst_mcast && !src_local) + if (ifa->type != OSPF_IT_PTP && dst_mcast && !src_local) LOG_PKT_WARN("Multicast packet received from non-link-local %I via %s", sk->faddr, ifa->ifname);
This is unnecessary. In OSPFv3, src_local is true on PtP networks as it is just link-local address.
@@ -535,6 +535,9 @@ ospf_iface_stubby(struct ospf_iface_patt *ip, struct ifa *addr) if (ip->type == OSPF_IT_VLINK) return 0;
+ if (ip->type == OSPF_IT_PTP) + return 0; +
What is that about? Is it unrelated to AllSPFRouters change?
There should be some change as the code in ospf_iface_stubby() forces any host address to stub network. That is too strong as PtP or PtMP can be valid with just host address. But this change must be done in a different 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 Sat, May 08, 2021 at 03:45:36PM +0000, Joakim Tjernlund wrote:
On Fri, 2021-05-07 at 14:03 +0000, Senthil Kumar Nagappan wrote:
Hi Jocke,
yes i missed to take care of the ospfv3/ipv6 cases wherever im sending using allospfrouters as src ip. your are right, mcast changes in packet.c is mostly hack since im not comfortable with the bird code since i have only 1 week of bird code experience. reason i did not change inside ospf_send_to() is,since dst address is one of the parameter to the function and i don't want to override inside it. In Hello.c, ospf_send_hello they do some what similar, checking different interface types before they call ospf_send_to()
Ondrej, what is your preference? Perhaps you want to do the impl. yourself?
Hi I think that ospf_send_to() should stay as lower-level function that send packet as it is told. I took the patch and refactored it a bit so most code uses either ospf_send_to_nbr() or ospf_send_to_iface(). Here: https://gitlab.nic.cz/labs/bird/-/commit/bc591061f618cdc35cf21c7973a660f8d70... (and the previous commit) Note that the original patch from Senthil also does some more changes i will merge in the next patch. I am splitting it to two independent changes: 1) Always use AllSPFRouters on PtP networks 2) Allow ifaces with just host address (and not peer address) as PtP ifaces. The second patch requires more work, is it is not commited yet. -- 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, May 06, 2021 at 05:09:53PM +0000, Senthil Kumar Nagappan wrote:
Hi, I did sent this message a week back but I could not see it in the mailing, moreover just now subscribed to this mailing list, so sending this again. I’m seeing some issues with ospf adj over ptpnumbered/unnumbered interface. 1. Forp2p connections, ospf should be sending only multicast packets toallospfrouters, but I see its sending to unicast address. (From RFC “On physical point-to-point networks, theIP destination is always set to the address AllSPFRouters”)
2. Forptp over unnumbered interface, bird requires peer address configuration whichis not required from the ospf perspective. Because bird is using peer addressand sending unicast packets, bird cannot form multiple ospf adj over ptpunnumbered interface between 2 endpoints using same peer address. Made some quick changes and have attached the patch thataddresses the issues. Relaxed the source ip address validation for ptp link inpacket.c for now. More validation can be added to make it complete. Thanks and Regards,Senthil
Hi Just finished some changes based on your suggestions. You can try it: https://gitlab.nic.cz/labs/bird/-/commit/2a0af925b83f699d126cf0e733a49c75ffd... (and two previous commits) - PtP ifaces shouls always use multicast - Allow OSPF PtP (or PtMP) on ifaces with just host address (/32) The later required some more changes that were not in your patch, e.g. using ONLINK flag for route nexthops on these unnumbered ifaces. -- 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."
participants (3)
-
Joakim Tjernlund -
Ondrej Zajicek -
Senthil Kumar Nagappan