Hi all
Have anyone encounter arp flux issues? (Different nic respond ping/traceroute to TIP or Int IP of another nic)
Currently I'm running Steelapp v9.8r2, in a cluster, 3 interfaces with one-arm deployment on each nics. So what happen is, a server 10.x.3.1,from eth3 side tries to ping/tracerote/connect TIP (10.x.2.200) or Int IP (10.x.2.254) in eth2, . Both ping and traceroute is succesful, but traceroute shows only one hop (rather than as suppose 2hops).
Reading from other linux issues was due to Sysctl arp flux in which other forum propose 2 Sysctl lines to be added;
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
So before going for open a tac or check, i would like to know if other fellow Steelapp users encounter the same issues. Your responce is highly appreciated.
owh...just to update. i have also deployed policy based routing, which if a device in eth2 segments needs to talk to device in eth3 segments, the will be force to cross over a firewall.
My PBR are
any source .2.x, go to .2.254, and use eth2
any source .3.x, go to .3.254, and use eth3
"My intention" example
1) Device(.2.1) <-->firewall(.2.254)<-->TIP SvcLAN (.3.100)<-->ServerLAN(3.1)
2) Device(.3.1) <-->firewall(.3.254)<-->TIP SvcDMZ (.2.200)<-->ServerDMZ(2.1)
"Real result" that im getting is
1) Device(.2.1) <-->TIP SvcLAN (.3.100)<-->ServerLAN(3.1)
2) Device(.3.1) <-->TIP SvcDMZ (.2.200)<-->ServerDMZ(2.1)
service failed to access, but ping and traceroute success