Skip to content
DnsLister Forum

Where domain hunters compare notes

Intermittent ARP failure for FreeBSD VNET jails behind VXLAN on Arista DCS-7150

────────────────────
SETUP
────────────────────

FreeBSD 15.1 with four VNET jails on the same L2 segment:

172.18.10.0/24
VLAN 1010
VXLAN VNI 10010

Jails:

• 172.18.10.10 — PostgreSQL (dns_pg_001)
• 172.18.10.11 — PowerDNS Authoritative
• 172.18.10.12 — PowerDNS Recursor
• 172.18.10.13 — Kea DHCP

The jails are connected locally through a FreeBSD ng_bridge.

The VXLAN VTEP extends this L2 segment to an Arista DCS-7150S-24-F running EOS 4.23.15M-2GB.

Arista SVI:

172.18.10.1/24

────────────────────
CONFIRMED OBSERVATIONS
────────────────────

The intermittent problem mainly affects 172.18.10.10.

After a period of inactivity, 172.18.10.10 has sometimes become unreachable from the Arista:

ping 172.18.10.10

Result:

100% packet loss

During such a failure, the Arista VXLAN MAC table contained:

589c.fc10.cfbe -> Vxlan1 -> 172.17.1.10

while the Arista ARP table did not contain a usable entry for:

172.18.10.10 -> 589c.fc10.cfbe

Packet captures showed that:

• the Arista ARP request reached the jail
• the jail generated an ARP reply
• FreeBSD encapsulated the reply into VXLAN with VNI 10010
• the encapsulated packet reached the Arista side
• no dynamic ARP entry for 172.18.10.10 appeared on the Arista

Similar behavior was also observed with 172.18.10.11, so the symptom is not unique to the PostgreSQL jail.

The jail MAC addresses are fixed.

────────────────────
WORKAROUND TESTED
────────────────────

I configured static ARP entries on the Arista.

For example:

arp 172.18.10.10 589c.fc10.cfbe arpa

After the VXLAN MAC entry for .10 was absent, Arista showed:

172.18.10.10 589c.fc10.cfbe Vlan1010, not learned

In that state:

• .10 was reachable from the T640 after more than 15 minutes of inactivity
• a subsequent ping from the Arista succeeded
• after that ping, Arista again showed 589c.fc10.cfbe dynamically learned on Vxlan1

The same recovery from “not learned” was also reproduced with .11.

────────────────────
INTERPRETATION / QUESTION
────────────────────

My current interpretation is that static ARP avoids dependence on the dynamic ARP learning/relearning behavior that previously caused loss of reachability, while VXLAN MAC learning remains dynamic.

I do not know whether static ARP is the usual workaround for DCS-7150 / EOS 4.23 with static VXLAN, or whether there is a standard configuration or known platform-specific fix for reliable dynamic ARP learning in this setup.

Has anyone seen this behavior on DCS-7150/FM6000 or EOS 4.23?

What is the usual solution?

Source: r/Arista · by /u/dmitry-n-medvedev

Leave a Reply

Your email address will not be published. Required fields are marked *