# cannot ping anymore



## PMc (Feb 1, 2021)

three hosts wired together directly on the same subnet

. host a can ping host b and host c
. host b can ping host a
. host c can ping host a
. host c does not receive Arp requests sent by host b
. host b does not receive Arp requests sent by host c

no firewall

physical is vimage/vnet jails (same maschine all)

failure appeared after upgrade from 12.2p2 to 12.2p3, did work before

were to search for fault?


----------



## obsigna (Feb 1, 2021)

Sounds somehow what happened to me recently. I set up another VM running FreeBSD 12.2p2 by simply copying the image of a working VM to another host. Both VM ran fine except they could not see each other. The culprit was, that I needed to generate for the new VM a different HW address for the virtual network adapter, since the straight copy of the VM image maintained this, of course.

So, you want to check the HW address of the virtual network adapters of your VMs. Ping and other network traffic may only happen when the HW addresses are unique in the given network.


----------



## SirDice (Feb 1, 2021)

Ah, the bane of having duplicate MAC addresses. Microsoft's Hyper-V has (had?) a habit of generating duplicate MAC addresses, quite troublesome to find which VMs are causing it if you have a large network with multiple Hyper-V clusters. Duplicate MAC addresses will result in really weird networking issues.


----------



## PMc (Feb 1, 2021)

Good point, but this is not the case here: MAC are all properly different, configured in /etc/jail.conf, and visible in `ifconfig`. The bridge also shows these MAC:

```
# ngctl msg lanswitch: gettable
Rec'd response "gettable" (7) from "[9]:":
Args:   { numHosts=4 hosts=[ { addr=74:65:d1:16:41:
9e hook="link2" age=65535 staleness=14 } { addr=06:
1d:92:01:01:03 hook="link16" age=65535 staleness=3
} { addr=06:1d:92:01:01:07 hook="link17" age=65535
staleness=169 } { addr=06:1d:92:01:02:02 hook="link
0" age=65535 staleness=29 } ] }
```


----------



## SirDice (Feb 1, 2021)

How are a, b and c connected to each other? It almost sounds like A is a host with two networks (c and b are on seperate networks) and no routing enabled.


----------



## PMc (Feb 1, 2021)

SirDice said:


> How are a, b and c connected to each other?


They are connected to the same bridge.


SirDice said:


> It almost sounds like A is a host with two networks (c and b are on seperate networks) and no routing enabled.


No. All three are in the same network, and no routing configured.

Also, this configuration was working for more than a year with nothing changed. It was upgraded R.11.4 to R.12.2 with nothing changed. Only since yesterday, after upgrading R.12.2-p2 to R.12.2-p3 and rebooting (it was rebooted lots of times before and rc.d stuff well tested) it does not work anymore.

host a:

```
nge_lan_1u: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
       options=28<VLAN_MTU,JUMBO_MTU>
       ether 06:1d:92:01:02:02
       inet 192.168.97.17 netmask 0xfffffff0 broadcast 192.168.97.31
       media: Ethernet autoselect (1000baseT <full-duplex>)
       status: active
       nd6 options=1<PERFORMNUD>
```
host b:

```
nge_kerb_1l: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
       options=28<VLAN_MTU,JUMBO_MTU>
       ether 06:1d:92:01:01:07
       inet 192.168.97.25 netmask 0xfffffff0 broadcast 192.168.97.31
       media: Ethernet autoselect (1000baseT <full-duplex>)
       status: active
       nd6 options=9<PERFORMNUD,IFDISABLED>
```
host c:

```
nge_admn_1l: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
       options=28<VLAN_MTU,JUMBO_MTU>
       ether 06:1d:92:01:01:03
       inet 192.168.97.24 netmask 0xfffffff0 broadcast 192.168.97.31
       media: Ethernet autoselect (1000baseT <full-duplex>)
       status: active
       nd6 options=9<PERFORMNUD,IFDISABLED>
```

I tried `arp -ad` on host a.
After that, host a can still reach host b, but cannot reach host c anymore: arp requests for host c are sent by host a, but do not arrive at host c.
It then takes about 12-14 minutes until the arp entry somehow appears and IP works again.


----------



## Brian546 (Feb 3, 2021)

In my experience, vnet jails work wonderful on bare metal systems but are too unpredictable in hyper-v. I've had nothing but problems with them, so if I must use hyper-v I only use traditional (ip alias) jails.


----------



## PMc (Feb 5, 2021)

Current state of affairs:
Restarting host b+c did not solve the issue. Restarting the bridge did. Restarting the whole thing did not make the issue reappear. So for now it appears as a not-reproducible problem.


----------

