Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Weird temporary problem with quagga routing

    pfSense Packages
    1
    1
    733
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      Reiner030 last edited by

      Hi,

      we have 2 pfsense pairs for 2 buildings… the "old" side works correctly with 2.0.1 but in new site with "2.1-BETA1 (amd64) built on Wed Feb 27 04:47:52 EST 2013" I have again and again temporary routing problems...

      The firewall slave lose his internally routes  (and very rare time also the master):

      I have e.g. our icinga/nagios monitoring on network of side 1 and we check all firewalls and network equipment  of building 2, too:

      Icinga/192.168.1.9  ->  192.168.1.1/2/3 [pfsense-pair jws1] 192.168.6.1/2/3  <=== Transfer ===> 192.168.6.11/12/13 [pfsense-pair zws8] 192.168.8.1/2/3 -> switch admin network

      If the slave 192.168.6.12 is not reachable by icinga I got this routing:

      [2.1-BETA1][root@fw2.zws8.local]/root(6): route -n get 192.168.1.9
        route to: 192.168.1.9
      destination: default
            mask: default
          gateway: xx.xx.176.254  <=public IP GW
        interface: lagg0_vlan7        <= WAN interface
            flags: <up,gateway,done,static>recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
            0        0        0        0      1500        1        0

      but OSPF rooting seems allright:
      [2.1-BETA1][root@fw2.zws8.local]/root(7): vtysh -e "show ip route 192.168.1.9"
      Routing entry for 192.168.1.0/24
        Known via "ospf", distance 110, metric 20
        Last update 05:03:21 ago
          192.168.6.2, via lagg0_vlan6
          192.168.6.3, via lagg0_vlan6

      So my problem is… what take this buggy route alive ?

      It can't be an BETA problem because I hade this also on our 2.0.1-er firewalls but very rarely there:

      [2.0.1-RELEASE][root@fw1.jws1.local]/root(2): route -n get 192.168.66.11
        route to: 192.168.66.11
      destination: default
            mask: default
          gateway: xx.xx.176.1  <= public GW
        interface: lagg0_vlan2    <= WAN interface
            flags: <up,gateway,done,static>recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
            0        0        0        0      1500        1        0

      Interesting thing what helps in this cases:
      [2.0.1-RELEASE][root@fw1.jws1.local]/root(2): /etc/rc.reload_interfaces

      [2.0.1-RELEASE][root@fw1.jws1.local]/root(3): route -n get 192.168.6.11
        route to: 192.168.6.11
      destination: 192.168.6.11
          gateway: 192.168.6.12
        interface: lagg1_vlan6
            flags: <up,gateway,host,done,proto1>recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
            0        0        0        0      1500        1        0

      If OSPF is shutdown all works long time without problems.

      I found an OpenOSPF Problem/Fix and tested it out:
      http://forum.pfsense.org/index.php/topic,39995.0.html
      links to his blog:
      http://ouliakk.blogspot.com/2011/08/using-openospfd-with-freebsd-78.html

      The Fix / Workaround

      The concept is simple: create an IP alias where the network overlaps the existing IP/network.
      In our example, 192.168.11.0/24 is used to exchange OSPF information. Create an alias of 192.168.10.1/23. That way when the 192.168.11.0/24 route gets deleted, the systems will be accessible to each other over the 192.168.10.0/23 route.

      but this solution didn't help in this case :(

      Andy ideas please?

      Bests

      Reiner</up,gateway,host,done,proto1></up,gateway,done,static></up,gateway,done,static>

      1 Reply Last reply Reply Quote 0
      • First post
        Last post