arp cannot intuit interface index and type for 192.168.215.4

freebsd-version
12.3-RELEASE-p2

Code:
netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            216.185.71.1       UGS        igb0
127.0.0.1          lo0                UHS         lo0
192.168.215.0/24   192.168.215.4      UGS        igb0
192.168.215.41     link#1             UHS         lo0
192.168.216.0/24   link#1             U          igb0
192.168.216.41     link#1             UHS         lo0
192.168.216.179    link#1             UHS         lo0
216.185.71.0/25    link#1             U          igb0
216.185.71.41      link#1             UHS         lo0

Code:
nmap -v -sn 192.168.215.4
Starting Nmap 7.91 ( https://nmap.org ) at 2022-03-29 10:17 EDT
Initiating ARP Ping Scan at 10:17
Scanning 192.168.215.4 [1 port]
Completed ARP Ping Scan at 10:17, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 10:17
Completed Parallel DNS resolution of 1 host. at 10:17, 0.00s elapsed
Nmap scan report for 192.168.215.4
Host is up (0.00016s latency).
MAC Address: 00:15:17:57:84:3D (Intel Corporate)
Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds
           Raw packets sent: 1 (28B) | Rcvd: 1 (28B)

Code:
ping 192.168.215.4
PING 192.168.215.4 (192.168.215.4): 56 data bytes
ping: sendto: Invalid argument
ping: sendto: Invalid argument
^C
--- 192.168.215.4 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

Code:
arp 192.168.215.4
192.168.215.4 (192.168.215.4) -- no entry

Code:
arp -s 192.168.215.4 00:15:17:57:84:3D
arp: cannot intuit interface index and type for 192.168.215.4

What networking issue am I tripping over here? Why cannot I add this static route i/f?
 
Firewall? Interface not up?
On the source host:
Code:
service pf onestatus
pf.ko is not loaded

ifconfig igb0
igb0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=e523bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
    ether 70:85:c2:da:88:4f
    inet 216.185.71.41 netmask 0xffffff80 broadcast 216.185.71.127
    inet 192.168.216.41 netmask 0xffffff00 broadcast 192.168.216.255
    inet 192.168.216.179 netmask 0xffffff00 broadcast 192.168.216.255
    inet 192.168.215.41 netmask 0xffffff00 broadcast 192.168.215.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

The target i/f is evidently up as nmap can find it via its IP address and reports the correct MAC address. I have checked and no firewall is running on the target host.
 
The target i/f is evidently up as nmap can find it via its IP address and reports the correct MAC address.

Edit: wasn't looking

What is the deal with this route?
Code:
192.168.215.0/24   192.168.215.4      UGS        igb0
That cannot be correct. 192.168.215.0/24 is a directly connected network on igb0. Because it's a directly connected network the route is implicitly coupled to link#1 (igb0), it shouldn't have a gateway address because it doesn't need one (it's directly connected).
 
That cannot be correct. 192.168.215.0/24 is a directly connected network on igb0. Because it's a directly connected network the route is implicitly coupled to link#1 (igb0), it shouldn't have a gateway address because it doesn't need one (it's directly connected).
It is a split route used solely on my workstation for testing purposes. 192.168.215.0/24 does not have a corresponding network address on the default router. The target of the static route is on a different host with a parallel connection to our ISP gateway;123.123.123.3 vice 123.123.123.2 for our existing gateway.

The arp problem was solved by rebooting the host. I originally tried using: service netif restart && sleep 5 && service routing restart but that gave the results detailed above. After the re-boot the arp table was properly populated.

Code:
arp 192.168.215.4
? (192.168.215.4) at 00:15:17:57:84:3d on igb0 expires in 1001 seconds [ethernet]

Requiring a re-boot is a bit awkward but I do not need to repeat it. I am not certain that this qualifies as a defect in arp but it is an anomaly.
 
192.168.215.0/24 does not have a corresponding network address on the default router.
That is irrelevant from the host's point of view. It's on a directly connected network, so the host already knows it can reach addresses in that range via igb0.
 
if you have an ip dest/route for that subnet then you don't need arp (for the other ips)
so the config is somewhat invalid
also add the alias on the as /32 (192.168.216.179)
 
Without the static route what happens to a packet destined to an outside address from a jail that only has a 192.168.215.0/16 address? ? It goes out the default gateway correct? In which case it is not going through the parallel gateway host that listens on 192.168.215.4. Which means I cannot test the nat setup and several other things respecting pf configuration that I need to have clear in my head. The existing gateway uses IPTABLES so its configuration is non-transferable.

I am driven to do this because I left my laptop at home and I cannot disconnect my workstation from the main network. Perviosuly I was working with a detached LAN segment so this kludge was unnecessary.
 
Without the static route what happens to a packet destined to an outside address from a jail that only has a 192.168.215.0/16 address?
You're making a mess of things by supernetting here. If the destination is within 192.168.215.0/24 (192.168.215.4 is within that range) or 192.168.216.0/24 (also connected to igb0), that will go out igb0 because 192.168.215.0/24 and 192.168.216.0/24 are directly accessible there. The rest of the /16 will be routed to your default gateway unless it's one of the other IPs in that range that are bound to lo0.
 
Back
Top