I've got two firewalled VMs connected to the same vLAN but I see RST/ACK responses on initial connection attempts in a while only to succeed on immediate following attempts, like some sort of cache needs to be initiated of peers. Wondering what might cause such, arp cache maybe?
Initial connection attempt:
15:04:56.786105 IP <redacted>.185.60362 > <redacted>.154.ldap: Flags [S], seq 3402 134510, win 26880, options [mss 8960,sackOK,TS val 429607411 ecr 0,nop,wscale 7], length 0
15:04:56.786377 IP <redacted>.154.ldap > <redacted>.185.60362: Flags [R.], seq 0, ack 3402134511, win 0, length 0
Following successful attempt:
15:05:11.363088 IP <redacted>.154.ldap > <redacted>.185.60378: Flags [S.], seq 310 2507846, ack 3252771331, win 26844, options [mss 8960,sackOK,TS val 538726974 ecr 429621988,nop,wscale 7], length 0
15:05:11.363120 IP <redacted>.185.60378 > <redacted>.154.ldap: Flags [.], ack 1, win 210, options [nop,nop,TS val 429621988 ecr 538726974], length 0
On destination VM I'm seeing relative frequent arp requests like these whenever there's communication otherwise not, like server wants to ensure client peers is still there (on the same HN maybe though mac-addr should change during live migration, switches might need to know this quickly):
18:56:08.164227 ARP, Request who-has <redacted>.184 tell <redacted>.154, length 28
18:56:08.164687 ARP, Reply <redacted>.184 is-at 62:38:31:33:39:39, length 46
It appears as expected that I've got no duplicate IP addresses assigned, so why would peers keep sending relative many arp req.s?
[root@dcs2 ~]# arping -DI eth1 <redacted>.184
ARPING <redacted>.184 from 0.0.0.0 eth1
Unicast reply from <redacted>.184 [62:38:31:33:39:39] 1.122ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
#n1:/> arping -DI eth1 <redacted>.154
ARPING <redacted>.154 from 0.0.0.0 eth1
Unicast reply from <redacted>.154 [6E:FF:D6:F0:78:C6] 1.107ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
It could appear to be arp cache warm-up issue if I do an arping first there's no initial issue:
#n2:/> arping -I eth1 -f dcs4.<redacted>; telnet dcs4.<redacted> 389
ARPING <redacted>.156 from <redacted>.185 eth1
Unicast reply from <redacted>.156 [92:B9:56:CE:03:E6] 1.150ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
Trying <redacted>.156...
Connected to dcs4.<redacted>.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
But how to avoid the initial issue in general as it affects our applications?
0 Answers