# arp cannot intuit interface index and type for 192.168.215.4



## byrnejb (Mar 29, 2022)

freebsd-version
12.3-RELEASE-p2


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


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


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


```
arp 192.168.215.4
192.168.215.4 (192.168.215.4) -- no entry
```


```
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?


----------



## SirDice (Mar 29, 2022)

Firewall? Interface not up?


----------



## byrnejb (Mar 29, 2022)

SirDice said:


> Firewall? Interface not up?


On the source host:

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


----------



## SirDice (Mar 29, 2022)

byrnejb said:


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

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


----------



## byrnejb (Mar 29, 2022)

SirDice said:


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


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


----------



## SirDice (Mar 29, 2022)

byrnejb said:


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


----------



## covacat (Mar 29, 2022)

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)


----------



## byrnejb (Mar 29, 2022)

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.


----------



## SirDice (Mar 29, 2022)

byrnejb said:


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


----------

