Problem with FRR in 2.5.0



  • Hi,

    since I was having trouble with FRR on the latest production versions (as described here), I am testing the same thing on 2.5.0.

    After "solving" crashing problems I have four devices running again, which all manage to connect to two other pfSense boxes via IPSec. The problem I'm having here is that routes don't seem to be added - under

    ============ OSPF network routing table ============
    

    in FRR status I get nothing - while I'm pretty sure that it was there earlier, when using 2.4.3. Also, I was able to get this to work better on 2.4.3, in the sense that at least some connections worked (see first link above for details).

    OSPF Neighbours shows something like this on all four devices:

    Neighbor ID     Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
    192.168.12.1      1 Full/DROther      38.935s 192.168.88.3    ipsec1000:192.168.88.2     0     0     0
    192.168.14.1      1 Full/DROther      39.472s 192.168.88.9    ipsec3000:192.168.88.8     0     0     0
    

    while OSPF Routes shows something like below:

    ============ OSPF network routing table ============
    
    ============ OSPF router routing table =============
    R    192.168.12.1          [2] area: 0.0.0.0, ASBR
                               via 192.168.88.3, ipsec1000
    R    192.168.14.1          [2] area: 0.0.0.0, ASBR
                               via 192.168.88.9, ipsec3000
    
    ============ OSPF external routing table ===========
    N E2 10.xx.0.0/23          [2/20] tag: 0
                               via 192.168.88.3, ipsec1000
                               via 192.168.88.9, ipsec3000
    N E2 192.168.88.2/31       [2/20] tag: 0
                               via 192.168.88.3, ipsec1000
    N E2 192.168.88.4/31       [2/20] tag: 0
                               via 192.168.88.3, ipsec1000
    N E2 192.168.88.6/31       [2/20] tag: 0
                               via 192.168.88.9, ipsec3000
    N E2 192.168.88.8/31       [2/20] tag: 0
                               via 192.168.88.9, ipsec3000
    

    In Diagnostic -> Routes I get this:

    Destination	Gateway	Flags	Use	Mtu	Netif	Expire
    default	10.xx.0.1	UGS	516	1500	re1	
    10.xx.0.0/23	link#2	U	2131	1500	re1	
    10.xx.0.1	00:0d:b9:xx:xx:xx	UHS	446	1500	re1	
    10.xx.1.201	link#2	UHS	0	16384	lo0	
    127.0.0.1	link#5	UH	72	16384	lo0	
    192.168.11.0/24	link#3	U	0	1500	re2	
    192.168.11.1	link#3	UHS	0	16384	lo0	
    192.168.21.0/24	link#1	U	0	1500	re0	
    192.168.21.1	link#1	UHS	0	16384	lo0	
    192.168.88.2	link#8	UHS	0	16384	lo0	
    192.168.88.3	link#8	UH	412	1500	ipsec1000	
    192.168.88.4/31	192.168.88.3	UG1	0	1500	ipsec1000	
    192.168.88.6/31	192.168.88.9	UG1	0	1500	ipsec3000	
    192.168.88.8	link#9	UHS	0	16384	lo0	
    192.168.88.9	link#9	UH	408	1500	ipsec3000	
    

    When trying to SSH from one device to another, via their internal addresses, eg 192.168.12.1 -> 192.168.11.1, I can see traffic showing up going out on the WAN interface on the originating device - obviously, this doesn't reach it's target.

    Any ideas why this isn't working?



  • So, I found the answer to this..
    Apparently, if the LAN interface is down because there is nothing connected to it, it is also not "sent out" by FRR, ie not routes are created. After connecting a device to each LAN port, I get the routes as expected.

    Now I'm back to where I was in pfSense 2.4.4-p3 :)



  • If the interface is down it isn't participating in the routing.
    Nothing unusual about that behavior which is exactly what you'd expect on a Cisco router, possibly other brands as well.
    You can use loopback interfaces to "fake" certain networks which must always be up.



  • Yeah, not a big problem - just that as i remember, the behaviour was different when I tried with 2.4.4. That's why it had me stumped for a while. On the other hand, I've been testing a lot of things and changing versions / settings so I might be wrong..


Log in to reply