Запрос ping не проходит первый запрос на одной подсети/сетевом адаптере. Остальной трафик очень медленный

Запрос ping не проходит первый запрос на одной подсети/сетевом адаптере. Остальной трафик очень медленный

У меня есть сервер с двумя сетевыми картами, каждая из которых настроена на отдельную подсеть:

NIC1 xxx.xx.151.10, mask 255.255.252.0, gateway xxx.xx.148.1
NIC2 xxx.xx.148.10, mask 255.255.255.0, gateway None, but I tried setting same as NIC1 to see if it helped. Did not.

С сервера, когда я пингую устройство в подсети 148 (например, IP-принтер или даже шлюз), первый запрос всегда возвращается с Destination Host Unreachable в качестве ответа от NIC2. После этого остальные запросы в порядке. Аналогично, когда я отправляю запрос устройству в подсети 148 (в данном случае задание на печать), первая попытка очень медленная, а затем последующие печати проходят нормально. Если я ничего не отправляю данному устройству в течение ~15 секунд, оно возвращается в исходное состояние.

В подсети 151 есть несколько принтеров, у которых такой проблемы нет.

Итак, как устранить эту первоначальную задержку?

Дополнительная информация: Сервер: Windows Server 2008 R2

Pinging xxx.xx.148.1 with 32 bytes of data:
Reply from xxx.xx.148.10: Destination host unreachable.
Reply from xxx.xx.148.1: bytes=32 time=2ms TTL=64
Reply from xxx.xx.148.1: bytes=32 time=1ms TTL=64
Reply from xxx.xx.148.1: bytes=32 time=1ms TTL=64

Ping statistics for xxx.xx.148.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 2ms, Average = 1ms

netstat -rn:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     xxx.xx.148.1    xxx.xx.151.10    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
     xxx.xx.148.0    255.255.252.0         On-link     xxx.xx.151.10    266
     xxx.xx.148.0    255.255.255.0         On-link     xxx.xx.148.10    266
    xxx.xx.148.10  255.255.255.255         On-link     xxx.xx.148.10    266
   xxx.xx.148.255  255.255.255.255         On-link     xxx.xx.148.10    266
    xxx.xx.151.10  255.255.255.255         On-link     xxx.xx.151.10    266
   xxx.xx.151.255  255.255.255.255         On-link     xxx.xx.151.10    266
      192.168.1.0    255.255.255.0         On-link       192.168.1.2    266
      192.168.1.2  255.255.255.255         On-link       192.168.1.2    266
    192.168.1.255  255.255.255.255         On-link       192.168.1.2    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     xxx.xx.151.10    266
        224.0.0.0        240.0.0.0         On-link     xxx.xx.148.10    266
        224.0.0.0        240.0.0.0         On-link       192.168.1.2    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     xxx.xx.151.10    266
  255.255.255.255  255.255.255.255         On-link     xxx.xx.148.10    266
  255.255.255.255  255.255.255.255         On-link       192.168.1.2    266
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0     xxx.xx.148.1  Default 
          0.0.0.0          0.0.0.0   xxx.xx.150.250  Default 
===========================================================================

EDIT 30 мая 2014 Это было некоторое время назад, и некоторые детали туманны, но я хотел включить свое решение здесь. В конечном итоге нам пришлось переместить группу принтеров из подсети 148 в (к счастью, не используемую) подсеть 150. Как я уже сказал, я не совсем помню точный вывод относительнопочемуэто произошло, но это было связано с маской подсети и используемыми нами подсетями, что привело к конфликту.

Связанный контент