locked
One server can't ping another server on one network card, but it works in reverse, and works to other servers RRS feed

  • 質問

  • I have a puzevzling issue.

    I have several Windows Server 2019 servers, each with 3 network connections. One connection of all servers (192.168.1.*) goes to a switch which also has internet access. The other 2 (192.168.2.* and 192.168.3.*) go to switches which just connect to the other servers.

    I can ping from each server to every other using the 192.168.2.* and 192.168.3.* addresses. I can ping from every server to server 192.168.1.123. I can ping from every other server to all servers on 192.168.1.*. But, I can't ping from 192.168.1.123 to 192.168.1.122. It works, as I say, in the other direction (I can ping from 192.168.1.122 to 192.168.1.123).

    I've tried disabling the Windows firewall, to no effect. I've tried disabling and enabling the 192.168.1.* network card in server .123. I've cleared the arp cache (but I'm using ip addresses for testing, so that shouldn't matter). I've checked the Route Print, and that looks the same on all of the servers.

    At this point, I'm scratching my head. Any ideas would be appreciated.

    Thank you.


    Jeremy Heymann Market Mentor Online

    2020年4月13日 5:19

回答

  • It turned out that there was an issue with the neighbor list. The main IP address for the server that couldn't be pinged wasn't in the arp -a list. It also couldn't be manually added with arp -s.

    I finally had to use netsh to manually add the entry for that IP address. It took hours to figure out the syntax. What I finally did was the following:

    "arp -a" to list what was there, and see another IP address for that machine, so I could find the mac address. If you don't have another IP address showing, you could look at another machine, or look on the target machine directly to find the mac address for that network card.

    netsh to go into the netsh program.

    Interface ipv4 to get into the section of netsh which would let me manipulate IPV4 stuff.

    add neighbor  "Remote 2" "192.168.1.121"  "12-34-56-78-9a-bc"

    In the above command, the first string is the name of the local network interface that you want to use to get to the neighboring system. Note that this is the same terminology as the Interface ipv4 command above, but it is NOT THE SAME. That parameter, or the earlier one should be named something else, for clarity.

    The second string is the ipv4 address of the target system. The third is the mac address of the network card on the target system.

    Unfortunately, this command created a permanent setting, so if I every change the environment, I will have to remember to go back here and remove or change that entry. I couldn't figure out how to replace what Windows should have done by itself. I also never figured out why Windows didn't do it in the first place. Restarting the systems didn't have any effect.

    Anyway, this was the answer for me. I hope this helps someone else.


    Jeremy Heymann Market Mentor Online

    2020年4月24日 13:49

すべての返信

  • Hi,
    Based on my understanding, you can ping from server 192.168.1.122 to server 192.168.1.123 while you can't ping from 192.168.1.123 to 192.168.1.122. Is this right?
    If my understanding is wrong, please feel free to correct me.
    For this situation, please make sure to disable the Windows firewall on both sides.
    Also, it's possible that even though Windows Firewall is OFF, if you have some third-party software like anti-virus software, they might block certain types of traffic.
    So if you have installed some third-party applications, please temporarily disable them to check whether the ping utility could succeed.
    Hope this can help you.

    Best regards,


    Phoebe Wu

    2020年4月14日 9:46
  • Hi,

    Just want to confirm the current situations. Was your issue resolved?

    Please feel free to let us know if you need further assistance.

    Best regards,

    Phoebe Wu

    2020年4月16日 1:43
  • We now have another ping issue. One Windows Server 2019 server isn't responding to pings from any source via one network connection. It responds to pings via other network connections, it can ping any other site, and other traffic, in either direction, works fine. I've tried turning off the firewalls on both sides, with no improvement. I tried pinging the address locally on the server, and that works.

    To get specific:

    Server 15 has 2 network cards, 192.168.1.115 and 192.168.2.115. Server 16 also has two network cards, 192.168.1.116 and 192.168.2.116. Both are connected to separate switches. From server 15, I can ping server 16 on either ip address, and I can access any other services on the other machine.

    From server 116 (and any of the other domain servers), I can ping server 15 via the 192.168.2.115, but not the 192.168.1.115 (or the IPV6 address for that connection). I can access \\192.168.1.115\c$, so it isn't that the card isn't working. Again, I have turned the firewalls off on both server 15 and server 16, without improvement.

    I've tried restarting server 15.

    Any suggestions?

    Thank you.


    Jeremy Heymann Market Mentor Online

    2020年4月19日 2:03
  • Hi,
    I have known about your issue. Since you have turned the firewalls off on both sides without any improvement, we will suggest that you can try to do the following steps:
    Third-party software like anti-virus software might block certain types of traffic. So if you have installed any third-party anti-virus software, we will suggest that you can uninstall them temporarily to check whether the ping utility could succeed.
    Also, we will suggest that you can update the network adaptor driver to the latest version. 
    If there’s still no improvement, you can run ‘arp -a’ in cmd on both server 15 and server 16 to check whether the pairs of IP addresses and corresponding MAC addresses are correct. 
    If the pairs of mapping are correct, we consider that you may have to use packet capture to analyze the specific reason of this ping issue. Unfortunately, please understand, analysis of network traffic is beyond our forum support level. If your issue is urgent, I would suggest you open a case with Microsoft where more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.
    Here is the link:

    Global Customer Service phone numbers

    Hope this can help you.

    Best regards, 

    Phoebe Wu


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   

    2020年4月21日 7:04
  • Hi,

    Just want to confirm the current situations. Was your issue resolved?

    If the information provided is helpful, please mark it as answered.

    Please feel free to let us know if you need further assistance.

    Best regards, 

    Phoebe Wu


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   

    2020年4月24日 1:36
  • It turned out that there was an issue with the neighbor list. The main IP address for the server that couldn't be pinged wasn't in the arp -a list. It also couldn't be manually added with arp -s.

    I finally had to use netsh to manually add the entry for that IP address. It took hours to figure out the syntax. What I finally did was the following:

    "arp -a" to list what was there, and see another IP address for that machine, so I could find the mac address. If you don't have another IP address showing, you could look at another machine, or look on the target machine directly to find the mac address for that network card.

    netsh to go into the netsh program.

    Interface ipv4 to get into the section of netsh which would let me manipulate IPV4 stuff.

    add neighbor  "Remote 2" "192.168.1.121"  "12-34-56-78-9a-bc"

    In the above command, the first string is the name of the local network interface that you want to use to get to the neighboring system. Note that this is the same terminology as the Interface ipv4 command above, but it is NOT THE SAME. That parameter, or the earlier one should be named something else, for clarity.

    The second string is the ipv4 address of the target system. The third is the mac address of the network card on the target system.

    Unfortunately, this command created a permanent setting, so if I every change the environment, I will have to remember to go back here and remove or change that entry. I couldn't figure out how to replace what Windows should have done by itself. I also never figured out why Windows didn't do it in the first place. Restarting the systems didn't have any effect.

    Anyway, this was the answer for me. I hope this helps someone else.


    Jeremy Heymann Market Mentor Online

    2020年4月24日 13:49
  • Hi,

    Thanks for sharing your detailed resolution here as it would be helpful to anyone who encounters similar issues.

    If there is anything else we can do for you, please feel free to post in the forum.

    Best regards, 

    Phoebe Wu

     

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   

    2020年4月27日 2:38