OpenOSPFD 4.2 is out at October 7th 2007 [1]. FreeBSD port is still at 4.0. Moreover, there are problems with multiple point-to-point interfaces selection logic in both 4.0 and 4.2 [2]. A fix was committed to the OpenBSD CVS [3], but it didn't get into 4.2. [1] ftp://ftp.openbsd.org/pub/OpenBSD/OpenBGPD/ [2] http://lists.freebsd.org/pipermail/freebsd-net/2008-February/016718.html [3] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ospfd/rde_spf.c?rev=1.64&content-type=text/x-cvsweb-markup Fix: The following patches will update the port to 4.2 and fix the issue with p2p interfaces. They received a limited testing by me and Josef Pojsl: look into the thread [2] starting with http://lists.freebsd.org/pipermail/freebsd-net/2008-February/016835.html First patch, just to make OpenOSPFD 4.2 work on FreeBSD. Patch from OpenBSD CVS that cures point-to-point interfaces selection logics: From 64d437bb476f5f4bb4716abd181289882a8378fa Mon Sep 17 00:00:00 2001 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> Date: Mon, 18 Feb 2008 14:29:16 +0300 Subject: [PATCH] Add patch that fixes selection logic for multiple p2p interfaces. In the original code, the first point-to-point interface on this router was chosen for the nexthop calculations, no matter what was the cost for this interface. This was fixed in the upstream repository, in rde_spf.c, version 1.64. Patch from http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ospfd/rde_spf.c.diff?r1=1.63&r2=1.64 Signed-off-by: Eygene Ryabinkin <rea-fbsd@codelabs.ru> --- files/patch-p2p_interfaces | 138 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 138 insertions(+), 0 deletions(-) create mode 100644 files/patch-p2p_interfaces How-To-Repeat: Look at the reference [1] and read the thread starting with [2].
Responsible Changed From-To: freebsd-ports-bugs->farrokhi Over to maintainer (via the GNATS Auto Assign Tool)
Good day. I forgot to mention that when the patch 4.0-to-4.2.patch is applied with 'patch -p1', one should delete (old and zero-sized) patch files files/patch-ospfctl_parser.c and files/patch-ospfctl_parser.h. Or use 'patch -p1 -E' to remove them automatically.
Reto, good day. Fri, May 30, 2008 at 07:43:56AM +0200, Reto Burkhalter wrote: > I just wanted to let you know, that I successfully patched, > compiled and tested your patch against a 4.0 port of openospfd > running on FreeBSD 6.3-p2. For me, almost everything works as espected. You mean that you updated your port from 4.0 to 4.2 and it mosly works? Good to hear, thanks! > There is one little issue that I have seen so far: > - you have two connections between two routers (e.g. lnc0 and ln lnc1), > one with a higer metric From the below, I assume that the names are lnc1 and lnc2? Or I am missing something? > - start ospfd > - adjacency are built (two FULL/DR resp. FULL/BDR) succcessfully > > ID Pri State DeadTime Address Iface > Uptime > 172.19.16.2 1 FULL/DR 00:00:38 10.0.1.2 lnc2 > 00:00:02 > 172.19.16.2 1 FULL/DR 00:00:38 192.168.1.2 lnc1 > 00:00:02 And here routing is taking place over the link with the higher metric? > - disabling one device (ifconfig lnc2 down) > May 30 07:37:46 router1 ospfd[1015]: send_packet: error sending packet > on interface lnc2: Network is down > May 30 07:37:46 router1 ospfd[1015]: interface lnc2 down > > ID Pri State DeadTime Address Iface > Uptime > 172.19.16.2 1 DOWN/DOWN 00:00:21 10.0.1.2 lnc2 - > 172.19.16.2 1 FULL/DR 00:00:36 192.168.1.2 lnc1 > 00:00:54 > > - rerouting takes place over the link with higher metric You mean that packets are routed via lnc1 or something else? I see only one alive interface, so it is automatically has the higher metric. > - enabling device (ifconfig lnc2 up) > May 30 07:38:33 router1 ospfd[1015]: interface lnc2 up > May 30 07:38:39 router1 ospfd[1015]: recv_db_description: seq num > mismatch, badflags > > - adjacency will not built up again: > > ID Pri State DeadTime Address Iface > Uptime > 172.19.16.2 1 EXCHG/DR 00:00:36 10.0.1.2 lnc2 - > 172.19.16.2 1 FULL/DR 00:00:36 192.168.1.2 lnc1 > 00:02:05 > > - will not come up again and stay in EXCHG or EXSTA > > But this can be a problem of the original ospfd, not the port.. OK, I will try to see what happens, but not very quickly -- main job waits ;)) By the way, what type of interface lncX is? Was it something standard, just renamed to lnc1 and lnc2 or it is some custom driver? I mostly interested if interfaces are point-to-point or broadcast. Thank you! -- Eygene
I'm also having issues with OpenOSPFD. The culprit to the problem is that I'm using MPD to terminate PPPoE connections from clients. I've configured the external ethernet adapter with an IP address, let's call it X. MPD creates netgraph nodes for each incoming connection, it's configured to set the local ip address of the link to the same address X (usual setup, which works). I first started OpenOSPFD. It uses the same ip address X as router-id. The external ethernet (whose IP is x) is set up for the only one area in it's config file. Everything works fine. UNTIL we start MPD. MPD starts working fine, but when the first user connects and the first netgraph node is created, OpenOSPFD loses connectivity. If we stop MPD, without restarting or touching OpenOSPFD at all, connectivity is restored. During the time MPD is started and at least one netgraph node is up, the ospf peer is seen as DOWN from the other network peers. I den tried starting OpenOSPFD after MPD was already started and a netgraph interface was present. The results were more than strange. OpenOSPFD joined the multicast group on ng0 instead of the network interface! Here it is: ng0 1480 213.137.48.4/ server4 528 - 2 - - >>! OSPF-ALL.MCAST.NE ALL-SYSTEMS.MCAST Weirdo! I then changed the IP address MPD sets up at the local side of the ng interfaces to another IP address (alias on the external ethernet address, so other routers know how to reach it), just for the test. OpenOSPFD works fine during mpd startup and ng interface creation. BUT it does not distribute routes for the connected netgraph nodes to the ospf nodes. I assume something is generally messed up here, and am willing to help resolve that problem. Many people need ospf + mpd setup, and many of them use custom software to redistribute the connected client IPs. A work which can be nicely done by the ospf daemon if it worked the way it's supposed to. The tests were conducted with the stock 4.0 version from the ports, as well as the 4.2 version with the p2p patch above. If I could be of any further help, please contact me. Doichin Dokov NetOne - Silistra Bulgaria
Doichin, good day. Mon, Jun 30, 2008 at 04:43:07AM +0300, NetOne - Doichin Dokov wrote: > I'm also having issues with OpenOSPFD. The culprit to the problem is > that I'm using MPD to terminate PPPoE connections from clients. > > I've configured the external ethernet adapter with an IP address, let's > call it X. MPD creates netgraph nodes for each incoming connection, it's > configured to set the local ip address of the link to the same address X > (usual setup, which works). Could you please post you configuration files (may be privately): I might be able to analyse the situation locally in my setup. -- Eygene Remember that it is hard to read the on-line manual while single-stepping the kernel. -- FreeBSD Developers handbook
The config is absolutely basic, here it is: router-id 1.2.3.4 fib-update yes auth-type crypt auth-md 1 ******* auth-md-keyid 1 redistribute connected area 0.0.0.1 { interface fxp0 } fxp0 is configured with IP address 1.2.3.4/28. Each tunnel MPD creates (netgraph nodes) has 1.2.3.4/32 set up as the local side. And, if the IPs are not the same, the wrong multicast group joining does not happen anymore, but openospfd is still unable to see netgraph nodes come up/down and thus distribute routes for them. I've discovered the same with the latest Quagga, the devs reacted promptly and it was fixed, maybe here it's something related, here's the PR - http://bugzilla.quagga.net/show_bug.cgi?id=465 Kind regards, Doichin.
Responsible Changed From-To: farrokhi->ehaupt Committer timeout. I will take care of it.
State Changed From-To: open->feedback I merged all the patches, could you please have a look at http://people.freebsd.org/~ehaupt/patches/openospfd.patch and give me feedback?
Responsible Changed From-To: ehaupt->freebsd-ports-bugs No resolution accomplished. Back to the queue.
State Changed From-To: feedback->open Feedback received.
Responsible Changed From-To: freebsd-ports-bugs->ehaupt I will take care of it.
State Changed From-To: open->closed Committed, thanks!
ehaupt 2008-11-27 20:54:31 UTC FreeBSD ports repository Modified files: net/openospfd Makefile distinfo net/openospfd/files patch-ospfctl_parser.c patch-ospfctl_parser.h patch-ospfd_kroute.c patch-ospfd_packet.c Added files: net/openospfd/files patch-ospfd_carp.c patch-ospfd_ospfd.c patch-ospfd_ospfd.h patch-ospfd_parse.y patch-ospfd_rde_spf.c Log: Update to 4.2 PR: 120788 Submitted by: Eygene Ryabinkin <rea-fbsd@codelabs.ru> Tested by: Doichin Dokov <root@net1.cc> Approved by: maintainer timeout Revision Changes Path 1.11 +1 -2 ports/net/openospfd/Makefile 1.5 +3 -3 ports/net/openospfd/distinfo 1.2 +2 -2 ports/net/openospfd/files/patch-ospfctl_parser.c 1.2 +13 -6 ports/net/openospfd/files/patch-ospfctl_parser.h 1.1 +22 -0 ports/net/openospfd/files/patch-ospfd_carp.c (new) 1.2 +119 -19 ports/net/openospfd/files/patch-ospfd_kroute.c 1.1 +27 -0 ports/net/openospfd/files/patch-ospfd_ospfd.c (new) 1.1 +13 -0 ports/net/openospfd/files/patch-ospfd_ospfd.h (new) 1.2 +18 -5 ports/net/openospfd/files/patch-ospfd_packet.c 1.1 +42 -0 ports/net/openospfd/files/patch-ospfd_parse.y (new) 1.1 +133 -0 ports/net/openospfd/files/patch-ospfd_rde_spf.c (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"