locked
Trace route timeout every step except last one RRS feed

  • Question

  • Hallo, I have a windows 2012 essentials that is my dc controller with dhcp, dns and so on and it has something wired with the network. If I try a trace route on every ip it returns just timeouts on each step except last one!
    Other aspect: I got another office, with it's own domain, connected via MPLS, so if I try to trace the server of the other domain from the problematic server no result, or better the same (timeouts every time except last), BUT if i try to trace the other server from any clients in the net of the problematic server all goes well! In fact I'm convinced that this strange behavior influences some other parts: an example is the shared folders, if i want to connect to the shares on the server connected via MPLS it returns an error, but from any other clients i've promted for the other domain and password and after that i can see all shared folders.

    Any ideas about that?!?

    Thank you all


    Acco

    Wednesday, October 28, 2015 10:43 PM

All replies

  • no one? :)

    Acco

    Thursday, October 29, 2015 10:10 AM
  • Do you have some examples you can share?

    Robert Pearman WSSMB MVP
    @titlerequired | LinkedIn | Google+
    Facebook | Windows Server Essentials.com

    Thursday, October 29, 2015 3:18 PM
  • Hi Robert, thanks for your reply!

    I attach these screenshot taken from server and a client on the same lan:

    SERVER to 8.8.8.8

    SERVER to other server via MPLS

    CLIENT to 8.8.8.8

    CLIENT to other server connected via MPLS


    Acco

    Thursday, October 29, 2015 6:54 PM
  • Hi,

    The TRACERT diagnostic utility determines the route to a destination by sending ICMP echo packets to the destination.

    Suppose that we tracert B(IP address) on device A.
    1. A sends ICMP - Echo request message with TTL equals 1 to B.
    2. Nearest router(such as Default Gateway) reply ICMP - Time Exceeded messages to A as TTL is decreased to 0. 

    ICMP - Echo request message with same TTL value will be sent 3 times. And the period of time is displayed at each line of TRACERT commend. A waits for 4 seconds to receive the answer by default, it will send request again if no answer is received. Final answer about B is sent via ICMP – Echo Relay message to A.

    As your picture displays, the “*” on time column indicates that no ICMP - Time Exceeded message is received, and failed to calculate the time. Some routers may silently drop packets that have expired TTLs, and these packets are invisible to TRACERT. Or, protection software/firewall may discard specific packets. Or, message is not received in time.

    You may try to disable protection software/firewall temporarily and confirm the result. Or, using monitor tools(network monitor) to capture detail packets of this process. 

    >if i want to connect to the shares on the server connected via MPLS it returns an error, but from any other clients i've promted for the other domain and password and after that i can see all shared folders.
    What is the error message when access shares? Any change before this problem happened?

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Friday, October 30, 2015 6:03 AM
  • Hi Eve, thanks for your reply!

    I've already tried to disable firewalls (the software one inside windows server using "netsh advfirewall set allprofiles state off" on both servers) and a zywall (that's in the same lan of the problematic server).

    no differences!...

    I'm almost sure that the problem is somewhere in the "main" server. Another observation:

    as you can see by this screenshot if I try to trace from remote server on the ip of the main server after 192.168.120.113 it miss itself, but if I trace from remote server to client after the hop 192.168.120.113 it reaches the machine!

    To answer at the point about shared folders this is the error returned in each way:

    Last question: any change before this happened?
    Short answer: yes, some.
    Long answer: before the implementation of MPLS each server was alone, another aspect was that the address class, before MPLS the main server was 192.168.10.10 and remote was 192.168.2.10, after MPLS I've changed to 10.7.68.10 and 10.0.96.10 respectively (to uniform with the router ip setting given by MPLS project). After some weeks I've noticed some strange behaviors with the ip 10.7.68.10 (it was like sometimes no eth card in the computer!), so I've checked if there ware some problems to change ip address of a domain controller, I've disabled that network card and enabled the other one with the new address 10.7.68.9, run some script to update dns and so on and everything seems good.....but wasn't.

    Hope to give you as many informations to help me to resolve this situation!

    Thanks
    FABIO


    Acco


    • Edited by acco.tn Friday, October 30, 2015 11:30 PM
    Friday, October 30, 2015 6:23 PM
  • up...

    Acco

    Monday, November 2, 2015 10:31 PM
  • Though it's almost 5 years gone here for anyone else searching:

    https://www.reddit.com/r/sysadmin/comments/5r6yfa/completely_stumped_tracert_win10_and_ftrace_3rd/

    The problem seems to be that MS Hyper-V NetNAT rules seem to extended the Baseline Filtering Engine rules (see HKLM/System/CurrentControlSet/Services/BFE/Parameters) such to drop ICMP type 11 (TTL exceeded) messages. Traceroute requires ICMP type 11 from intermediate routers and type 0 (reply) from final host. For a certain amount of time these BFE rules were not even removed when removing NetNAT rules until MS fixed at least this. Unfortunately, I cannot confirm this.

    As per own experience these rules also seem to drop ICMP type 3 code 4 (fragmentation required but DF bit set) which in turn disables Path MTU discovery (PMTUD blackholes) and as a consequence may lead to dropped packets. If you have a kind of tunnel running over this (VPN, DirectAccess etc.) you'll experience strange behaviour like network shares being disconnected within file transfer and being available again seconds later etc.

    Tuesday, July 14, 2020 7:03 PM