Well, I'm seeing something similar but even odder.
The kernel route for the local subnet *appears* to be intact, but various
diagnostic tools seem to disagree on that.
The pfSense GUI page Diagnostics->Routes shows a fairly small IPv4 routing
table (20 routes including host routes for the LAN subnet).
Yet "netstat -rn -f inet | wc -l" shows... um... 24. Oh, this gets better and
better: my route table is flapping non-stop. When I started typing this
message less than 60 seconds ago "netstat -rn -f inet | grep 192.139.69" gave
me about 4 screenfuls of routes before I hit ^C.
Yet even when I clearly have a connected route (as seen through netstat) the
kernel refuses to send packets there:
(Whee - 30 seconds later the routes are back!)
# netstat -rn -f inet | grep ^192.139.69 ; ping 192.139.69.161
192.139.69.0/24 192.139.69.161 UG1 0 0 vlan0
192.139.69.2/32 192.139.69.161 UG1 0 0 vlan0
192.139.69.4/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.8/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.12/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.24/29 192.139.69.161 UG1 0 0 vlan0
192.139.69.40/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.48/28 192.139.69.161 UG1 0 0 vlan0
192.139.69.80/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.84/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.88/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.92/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.96/27 192.139.69.161 UG1 0 0 vlan0
192.139.69.100/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.104/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.108/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.112/30 192.139.69.161 UG1 0 0 vlan0
192.139.69.128/27 192.139.69.161 UG1 0 0 vlan0
192.139.69.160/28 192.139.69.161 UGC 100 29 vlan0
192.139.69.176/28 192.139.69.161 UG1 0 0 vlan0
192.139.69.192/27 192.139.69.161 UG1 0 0 vlan0
192.139.69.255/32 192.139.69.161 UG1 0 0 vlan0
PING 192.139.69.161 (192.139.69.161): 56 data bytes
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
^C
--- 192.139.69.161 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
#
And...
# tail /var/log/system.log
Jun 17 14:54:17 pfsense kernel: arplookup 192.139.69.161 failed: host
is not on local network
Jun 17 14:54:17 pfsense kernel: arpresolve: can't allocate route for
192.139.69.161
Jun 17 14:54:20 pfsense kernel: arplookup 192.139.69.161 failed: host
is not on local network
Jun 17 14:54:20 pfsense kernel: arpresolve: can't allocate route for
192.139.69.161
Jun 17 14:54:23 pfsense kernel: arplookup 192.139.69.161 failed: host
is not on local network
Jun 17 14:54:23 pfsense kernel: arpresolve: can't allocate route for
192.139.69.161
Jun 17 14:54:29 pfsense kernel: arplookup 192.139.69.161 failed: host
is not on local network
Jun 17 14:54:29 pfsense kernel: arpresolve: can't allocate route for
192.139.69.161
Jun 17 14:54:32 pfsense kernel: arplookup 192.139.69.161 failed: host
is not on local network
Jun 17 14:54:32 pfsense kernel: arpresolve: can't allocate route for
192.139.69.16CLOG▒▒|▒#
#
WTF is the garbage at the end of system.log?
One thing I do see (briefly!) in the routing table is a rather anomalous route
for 192.139.69.160/28 via 192.139.69.161. Which correlates perfectly with what
Hans reported... I'm going to try adding a "deny inet prefix {
192.139.69.160/28 }" to bgpd.conf and will report results.
-Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Commercial support available - https://portal.pfsense.org
