OpenOSPFD



  • I have had the OpenOSPFd v0.4 package running for a couple of weeks on my pfSense 1.2.3-RELEASE box which I am trying to use as one of many exit points for a local Wireless ISP spanning several counties.  It worked fine with IOS, mikrotik, ImageStream, and StarOS hosts.  Both ImageStream and StarOS are using Quagga.

    When it installed routes in the kernel routing table, they had flags of UG2.  Normal kernel static routes had flags of UGS.  I could easily tell where the routes came from.

    The new version seems to not install the routes that way.  It just sets the UG flags.  That's what the Quagga /Linux based boxes do, so I'm disappointed but not too much so.

    I noticed that the v0.5 package was available yesterday and installed it.  My network was instantly trashed.  We also had problems with a lot of the Canopy backhauls which were on the same, large, bridge with one of the pfSense box's interfaces.  I couldn't access the pfSense box over any of the three ethernet interfaces.  I had to have the remote hands power off the pfSense box and quickly reconfigure the mikrotik sitting beside it to be able to do both jobs.

    Today I came on-site with a console cable and have been carefully trying to figure out what broke.

    I connected just one OSPF interface and lost connectivity to the box.  I couldn't even ping it from hosts on the same subnet.  Over the console cable, I noticed that the route for the connected subnet, was flagged "UGC" and pointed at the mikrotik on the same interface.  It also had host routes for my laptop and itself which were pointed at the mikrotik.

    
    /root(27): netstat -rn | grep 64.250.43.
    64.250.43.0/28     66.139.173.50      UGC         0        0    em1
    64.250.43.1        66.139.173.50      UGHW3       0        6    em1   3584
    64.250.43.7        66.139.173.50      UGHW3       0       97    em1   3600
    64.250.43.16/29    66.139.173.50      UG          0        2    em1
    64.250.43.252/30   66.139.173.50      UG          0        0    em1
    
    
    # ping 64.250.43.1
    PING 64.250.43.1 (64.250.43.1): 56 data bytes
    ping: sendto: No route to host
    ping: sendto: No route to host
    
    

    After killing ospfd I had no routes to my connected subnets which are also are connected to the mikrotik and therefore have routes which could be learned via ospf.

    After```
    ifconfig em0 64.250.43.1/28

    
    

    /root(44): netstat -rn | grep 64.250.43.
    64.250.43.0/28    link#1            UC          0        0    em0
    64.250.43.7        00:1d:72:3e:3e:18  UHLW        1      10    em0  1116

    
    I guess I need to get OpenOSPFd installed on a full FreeBSD install and learn what options are available.  I've not had much luck with googling for specifics.  I just wanted to report "here be dragons" with the new pfSense OpenOSPFd v0.5 package.
    
    I really wish I could figure out how to install quagga on pfSense nanobsd based systems without having to build my own image.  I don't care about having a GUI for dynamic routing protocols.


  • Looks like you're seeing the same problem I ran into with openospfd 4.6. If you pkg_delete the 4.6 package and grab 4.3 from http://files.pfsense.org/packages/7/All/ it will go back to as it was before.

    4.6 is working in other scenarios, but it has some major problems in some areas, possibly limited to FreeBSD 7.x as it appears to be fine on 2.0. The problem you're seeing specifically is it's hosing its routing table likely because it's getting a route via OSPF for a locally connected subnet, at least that's what I was seeing. Ermal is still looking at that one.



  • So, mount -u -o rw /  then pkg_delete openospfd-4.6 && pkg_add -r http://files.pfsense.org/packages/7/All/openospfd-4.3.tbz, rather than using the pfSense package manager? In this manner leaving the pfSense GUI code alone and just rolling back the openospfd FreeBSD package?

    I did notice, after my post, that pkg_info showed both packages installed.  I used the pfSense GUI to deinstall openospfd but the FreeBSD package remained.  I had to remount / and pkg_delete both openospfd packages manually.

    Now that I have figured out that I can just remount / when needed, I'm tempted to just pkg_add quagga, but I'll give this another try just for thoroughness.  :-)



  • @lambert:

    So, mount -u -o rw /  then pkg_delete openospfd-4.6 && pkg_add -r http://files.pfsense.org/packages/7/All/openospfd-4.3.tbz, rather than using the pfSense package manager? In this manner leaving the pfSense GUI code alone and just rolling back the openospfd FreeBSD package?

    Right. The GUI code works the same with either version.

    I don't know that quagga would be any better, and you'd have to do some hacking (maybe not much) to keep the things it needs rw in RAM.



  • Out of curiosity: has any develper considered developing quagga package and if yes then why was it rejected? Both OSPF and BGP work nice with 1.2.3-RELEASE.



  • We wouldn't reject a package, if someone wants to contribute a quagga package, knock yourself out.

    We went with openospfd because we only needed OSPF, it worked fine in all our initial testing and does everything the customer who funded the work needs it to do.

    There's also this:
    http://groups.google.com/groups/search?hl=en&q=quagga+group:bugtraq&qt_s=Search+Groups
    http://groups.google.com/groups/search?hl=en&q=openospfd+group:bugtraq&btnG=Search&sitesearch=

    openospfd has a vastly better security track record, as is typical of anything from OpenBSD.



  • After rolling back the package to openospfd-4.3, it seems to be behaving itself.



  • Thanks for the info, I downgraded the package to 4.3 for the time being.


Log in to reply