У меня есть две виртуальные машины с брандмауэром, подключенные к одной и той же vLAN, но я вижу ответы RST / ACK на начальные попытки подключения через некоторое время только для успеха при немедленных последующих попытках, например, для одноранговых узлов необходимо инициировать какой-то кеш. Хотите знать, что может вызвать такое, может быть, кеш arp?
Попытка первоначального подключения:
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
После успешной попытки:
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
На целевой виртуальной машине я вижу относительно частые запросы arp, подобные этим, когда связи нет, в противном случае, например, сервер хочет убедиться, что клиентские узлы все еще существуют (на том же HN, возможно, хотя mac-addr должен измениться во время живой миграции, коммутаторам может потребоваться знать это быстро):
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
Похоже, как и ожидалось, мне не назначены повторяющиеся IP-адреса, так почему одноранговые узлы продолжают отправлять относительное количество запросов arp?
[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)
Может показаться, что проблема с прогревом кэша arp, если я сначала сделаю arping, нет начальной проблемы:
#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.
Но как вообще избежать первоначальной проблемы, поскольку она влияет на наши приложения?