Problem with FRR in 2.5.0

mi8088 · Oct 15, 2019, 12:56 PM

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?

mi8088 · Oct 24, 2019, 1:19 PM

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 :)

awebster · Oct 24, 2019, 2:01 PM

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.

mi8088 · Oct 24, 2019, 2:26 PM

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..