This shows you the differences between two versions of the page.

Link to this comparison view

techblog:arp_flux [2018/09/01 20:14] (current)
bodik created
Line 1: Line 1:
 +# linux, zywall and arp flux
 +* once upon a time we had an small network with 2 mailservers (L,M) communicating with each other through zywall USG100 (Z). Z has 2 interfaces with different IPs from one subnet, also L. M was natted behind Z. From time to time, L was not able to communicate with M. After some time, while playing with tcpdump, firewall rules and any stuff we found i tried to check L2 layer .. HUH. What a surprise. It turns out, that our problem was ARP Flux, phenomenon of linux kernel arp/ip stack implementation ...
 +* http://​book.chinaunix.net/​special/​ebook/​oreilly/​Understanding_Linux_Network_Internals/​0596002556/​understandlni-CHP-28-SECT-4.html
 +* http://​linux-ip.net/​html/​ether-arp.html
 +Z replied on arp who-has from both interfaces, and L chooses wrong answer from time to time. Because ARP was populated, subsequent arp request was not sent to broadcast, but to specific mac, just to refresh arp cache entry. When we cleaned arp table, first request was sent to broadcast and both replys showed up .. huh. never saw it before.
 +/​home/​bodik#​ cat arp.py
 +#! /​usr/​bin/​env python
 +# arping2tex : arpings a network and outputs a LaTeX table as a result
 +import sys
 +if len(sys.argv) != 2:
 +    print "​Usage:​ arping2tex <​net>​\n ​ eg: arping2tex​24"​
 +    sys.exit(1)
 +from scapy import srp,​Ether,​ARP,​conf
 +ans,​unans=srp(Ether(dst="​ff:​ff:​ff:​ff:​ff:​ff"​)/​ARP(pdst=sys.argv[1]),​ timeout=2)
 +for snd,rcv in ans:
 +    print rcv.sprintf(r"​%Ether.src% & %ARP.psrc%"​)
 +/​home/​bodik#​ python arp.py ​ xx.yy.102.1/​32
 +00:​zz:​ww:​09:​21:​96 & xx.yy.102.1
 +# tcpdump arp
 +00:​10:​48.789724 arp who-has xx.yy.102.1 tell xx.yy.102.8
 +00:​10:​48.790086 arp reply xx.yy.102.1 is-at 00:​zz:​ww:​09:​21:​96
 +00:​10:​48.790116 arp reply xx.yy.102.1 is-at 00:​zz:​ww:​09:​21:​95
 +/​home/​bodik#​ python arp.py ​ xx.yy.102.2/​32
 +00:​zz:​ww:​09:​21:​96 & xx.yy.102.2
 +# tcpdump arp
 +00:​10:​36.032704 arp who-has xx.yy.102.2 tell xx.yy.102.8
 +00:​10:​36.033048 arp reply xx.yy.102.2 is-at 00:​zz:​ww:​09:​21:​96
 +00:​10:​36.033088 arp reply xx.yy.102.2 is-at 00:​zz:​ww:​09:​21:​95
 +Zyxel support stated, that this behavior is quite fine, and it's part of some security policy. I think that linux would handle cross mac/ip communication in kernel fine, but zywall blocks it since it is not really by the rules, and so it prevents arp poisoning/​manipulating attacks.
  • techblog/arp_flux.txt
  • Last modified: 2018/09/01 20:14
  • by bodik