Traceroute on a hop gives timeout












0














I was just looking into traceroute and trying to understand it's behaviour. Theoretically I get how IP routing and how traceroute work, but this case baffles me.



traceroute to google.com.ar (172.217.162.3), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 1.935 ms 1.367 ms 1.271 ms
2 10.38.0.1 (10.38.0.1) 9.717 ms 11.107 ms 13.901 ms
3 10.242.3.165 (10.242.3.165) 10.858 ms 11.663 ms 10.366 ms
4 cpe-200-115-194-173.telecentro-reversos.com.ar (200.115.194.173) 12.070 ms 11.944 ms 11.704 ms
5 cpe-200-115-194-174.telecentro-reversos.com.ar (200.115.194.174) 11.402 ms 12.110 ms 11.167 ms
6 74.125.242.209 (74.125.242.209) 13.539 ms 13.080 ms 11.767 ms
7 216.239.58.217 (216.239.58.217) 10.603 ms 11.635 ms 10.811 ms
8 eze04s07-in-f3.1e100.net (172.217.162.3) 11.510 ms 11.575 ms 10.955 ms


There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination



traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 1.777 ms 1.481 ms 2.287 ms
2 * * *
3 * * *


Nothing



Lets try with traceroute -I as pointed here:



Why does traceroute fail?



traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 72 byte packets
1 192.168.0.1 (192.168.0.1) 1.686 ms 1.218 ms 1.145 ms
2 * * *
3 * * *


Neither...



Whats going on?



traceroute -v
Version 1.4a12+Darwin


Connection: LAN connected to WAN using broadband router Cisco DPC3925










share|improve this question













migrated from serverfault.com Dec 14 at 23:46


This question came from our site for system and network administrators.




















    0














    I was just looking into traceroute and trying to understand it's behaviour. Theoretically I get how IP routing and how traceroute work, but this case baffles me.



    traceroute to google.com.ar (172.217.162.3), 64 hops max, 52 byte packets
    1 192.168.0.1 (192.168.0.1) 1.935 ms 1.367 ms 1.271 ms
    2 10.38.0.1 (10.38.0.1) 9.717 ms 11.107 ms 13.901 ms
    3 10.242.3.165 (10.242.3.165) 10.858 ms 11.663 ms 10.366 ms
    4 cpe-200-115-194-173.telecentro-reversos.com.ar (200.115.194.173) 12.070 ms 11.944 ms 11.704 ms
    5 cpe-200-115-194-174.telecentro-reversos.com.ar (200.115.194.174) 11.402 ms 12.110 ms 11.167 ms
    6 74.125.242.209 (74.125.242.209) 13.539 ms 13.080 ms 11.767 ms
    7 216.239.58.217 (216.239.58.217) 10.603 ms 11.635 ms 10.811 ms
    8 eze04s07-in-f3.1e100.net (172.217.162.3) 11.510 ms 11.575 ms 10.955 ms


    There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination



    traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 52 byte packets
    1 192.168.0.1 (192.168.0.1) 1.777 ms 1.481 ms 2.287 ms
    2 * * *
    3 * * *


    Nothing



    Lets try with traceroute -I as pointed here:



    Why does traceroute fail?



    traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 72 byte packets
    1 192.168.0.1 (192.168.0.1) 1.686 ms 1.218 ms 1.145 ms
    2 * * *
    3 * * *


    Neither...



    Whats going on?



    traceroute -v
    Version 1.4a12+Darwin


    Connection: LAN connected to WAN using broadband router Cisco DPC3925










    share|improve this question













    migrated from serverfault.com Dec 14 at 23:46


    This question came from our site for system and network administrators.


















      0












      0








      0







      I was just looking into traceroute and trying to understand it's behaviour. Theoretically I get how IP routing and how traceroute work, but this case baffles me.



      traceroute to google.com.ar (172.217.162.3), 64 hops max, 52 byte packets
      1 192.168.0.1 (192.168.0.1) 1.935 ms 1.367 ms 1.271 ms
      2 10.38.0.1 (10.38.0.1) 9.717 ms 11.107 ms 13.901 ms
      3 10.242.3.165 (10.242.3.165) 10.858 ms 11.663 ms 10.366 ms
      4 cpe-200-115-194-173.telecentro-reversos.com.ar (200.115.194.173) 12.070 ms 11.944 ms 11.704 ms
      5 cpe-200-115-194-174.telecentro-reversos.com.ar (200.115.194.174) 11.402 ms 12.110 ms 11.167 ms
      6 74.125.242.209 (74.125.242.209) 13.539 ms 13.080 ms 11.767 ms
      7 216.239.58.217 (216.239.58.217) 10.603 ms 11.635 ms 10.811 ms
      8 eze04s07-in-f3.1e100.net (172.217.162.3) 11.510 ms 11.575 ms 10.955 ms


      There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination



      traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 52 byte packets
      1 192.168.0.1 (192.168.0.1) 1.777 ms 1.481 ms 2.287 ms
      2 * * *
      3 * * *


      Nothing



      Lets try with traceroute -I as pointed here:



      Why does traceroute fail?



      traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 72 byte packets
      1 192.168.0.1 (192.168.0.1) 1.686 ms 1.218 ms 1.145 ms
      2 * * *
      3 * * *


      Neither...



      Whats going on?



      traceroute -v
      Version 1.4a12+Darwin


      Connection: LAN connected to WAN using broadband router Cisco DPC3925










      share|improve this question













      I was just looking into traceroute and trying to understand it's behaviour. Theoretically I get how IP routing and how traceroute work, but this case baffles me.



      traceroute to google.com.ar (172.217.162.3), 64 hops max, 52 byte packets
      1 192.168.0.1 (192.168.0.1) 1.935 ms 1.367 ms 1.271 ms
      2 10.38.0.1 (10.38.0.1) 9.717 ms 11.107 ms 13.901 ms
      3 10.242.3.165 (10.242.3.165) 10.858 ms 11.663 ms 10.366 ms
      4 cpe-200-115-194-173.telecentro-reversos.com.ar (200.115.194.173) 12.070 ms 11.944 ms 11.704 ms
      5 cpe-200-115-194-174.telecentro-reversos.com.ar (200.115.194.174) 11.402 ms 12.110 ms 11.167 ms
      6 74.125.242.209 (74.125.242.209) 13.539 ms 13.080 ms 11.767 ms
      7 216.239.58.217 (216.239.58.217) 10.603 ms 11.635 ms 10.811 ms
      8 eze04s07-in-f3.1e100.net (172.217.162.3) 11.510 ms 11.575 ms 10.955 ms


      There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination



      traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 52 byte packets
      1 192.168.0.1 (192.168.0.1) 1.777 ms 1.481 ms 2.287 ms
      2 * * *
      3 * * *


      Nothing



      Lets try with traceroute -I as pointed here:



      Why does traceroute fail?



      traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 72 byte packets
      1 192.168.0.1 (192.168.0.1) 1.686 ms 1.218 ms 1.145 ms
      2 * * *
      3 * * *


      Neither...



      Whats going on?



      traceroute -v
      Version 1.4a12+Darwin


      Connection: LAN connected to WAN using broadband router Cisco DPC3925







      routing traceroute






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Dec 14 at 23:22









      dantebarba

      1033




      1033




      migrated from serverfault.com Dec 14 at 23:46


      This question came from our site for system and network administrators.






      migrated from serverfault.com Dec 14 at 23:46


      This question came from our site for system and network administrators.
























          1 Answer
          1






          active

          oldest

          votes


















          2















          There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination




          No. First of all, traceroute doesn't actually show what hop the previous router tried to resolve; it shows the address that this hop identifies itself with, which is not always the same address. (Note that the forwarded IP packets always have the original destination's IP address, not each hop's.)



          Each hop identifies itself by sending an ICMP "TTL exceeded" error packet, and needs to pick an apropriate source address for it. It will have several addresses on different interfaces too choose from – including various Internet-facing interfaces, plus management networks – and might use various address selection algorithms, e.g. something simple such as "use the lowest address numerically".



          In short, it can certainly be an address that the previous hop doesn't have any route for.



          The second problem (even if there are complete routes towards that address) is that both ping and traceroute identify the final hop by a voluntarily sent response. The device might have ping (ICMP echo) replies simply turned off. Or it might have a firewall that discards your ping/traceroute probes without sending any reply. (The address you're trying to reach looks like something an ISP would use internally for a management network, so it's very likely that their firewall only accepts packets from the ISP's own NOC and nowhere else.)






          share|improve this answer





















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "3"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1383719%2ftraceroute-on-a-hop-gives-timeout%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2















            There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination




            No. First of all, traceroute doesn't actually show what hop the previous router tried to resolve; it shows the address that this hop identifies itself with, which is not always the same address. (Note that the forwarded IP packets always have the original destination's IP address, not each hop's.)



            Each hop identifies itself by sending an ICMP "TTL exceeded" error packet, and needs to pick an apropriate source address for it. It will have several addresses on different interfaces too choose from – including various Internet-facing interfaces, plus management networks – and might use various address selection algorithms, e.g. something simple such as "use the lowest address numerically".



            In short, it can certainly be an address that the previous hop doesn't have any route for.



            The second problem (even if there are complete routes towards that address) is that both ping and traceroute identify the final hop by a voluntarily sent response. The device might have ping (ICMP echo) replies simply turned off. Or it might have a firewall that discards your ping/traceroute probes without sending any reply. (The address you're trying to reach looks like something an ISP would use internally for a management network, so it's very likely that their firewall only accepts packets from the ISP's own NOC and nowhere else.)






            share|improve this answer


























              2















              There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination




              No. First of all, traceroute doesn't actually show what hop the previous router tried to resolve; it shows the address that this hop identifies itself with, which is not always the same address. (Note that the forwarded IP packets always have the original destination's IP address, not each hop's.)



              Each hop identifies itself by sending an ICMP "TTL exceeded" error packet, and needs to pick an apropriate source address for it. It will have several addresses on different interfaces too choose from – including various Internet-facing interfaces, plus management networks – and might use various address selection algorithms, e.g. something simple such as "use the lowest address numerically".



              In short, it can certainly be an address that the previous hop doesn't have any route for.



              The second problem (even if there are complete routes towards that address) is that both ping and traceroute identify the final hop by a voluntarily sent response. The device might have ping (ICMP echo) replies simply turned off. Or it might have a firewall that discards your ping/traceroute probes without sending any reply. (The address you're trying to reach looks like something an ISP would use internally for a management network, so it's very likely that their firewall only accepts packets from the ISP's own NOC and nowhere else.)






              share|improve this answer
























                2












                2








                2







                There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination




                No. First of all, traceroute doesn't actually show what hop the previous router tried to resolve; it shows the address that this hop identifies itself with, which is not always the same address. (Note that the forwarded IP packets always have the original destination's IP address, not each hop's.)



                Each hop identifies itself by sending an ICMP "TTL exceeded" error packet, and needs to pick an apropriate source address for it. It will have several addresses on different interfaces too choose from – including various Internet-facing interfaces, plus management networks – and might use various address selection algorithms, e.g. something simple such as "use the lowest address numerically".



                In short, it can certainly be an address that the previous hop doesn't have any route for.



                The second problem (even if there are complete routes towards that address) is that both ping and traceroute identify the final hop by a voluntarily sent response. The device might have ping (ICMP echo) replies simply turned off. Or it might have a firewall that discards your ping/traceroute probes without sending any reply. (The address you're trying to reach looks like something an ISP would use internally for a management network, so it's very likely that their firewall only accepts packets from the ISP's own NOC and nowhere else.)






                share|improve this answer













                There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination




                No. First of all, traceroute doesn't actually show what hop the previous router tried to resolve; it shows the address that this hop identifies itself with, which is not always the same address. (Note that the forwarded IP packets always have the original destination's IP address, not each hop's.)



                Each hop identifies itself by sending an ICMP "TTL exceeded" error packet, and needs to pick an apropriate source address for it. It will have several addresses on different interfaces too choose from – including various Internet-facing interfaces, plus management networks – and might use various address selection algorithms, e.g. something simple such as "use the lowest address numerically".



                In short, it can certainly be an address that the previous hop doesn't have any route for.



                The second problem (even if there are complete routes towards that address) is that both ping and traceroute identify the final hop by a voluntarily sent response. The device might have ping (ICMP echo) replies simply turned off. Or it might have a firewall that discards your ping/traceroute probes without sending any reply. (The address you're trying to reach looks like something an ISP would use internally for a management network, so it's very likely that their firewall only accepts packets from the ISP's own NOC and nowhere else.)







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Dec 15 at 0:05









                grawity

                232k35490546




                232k35490546






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Super User!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1383719%2ftraceroute-on-a-hop-gives-timeout%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Probability when a professor distributes a quiz and homework assignment to a class of n students.

                    Aardman Animations

                    Are they similar matrix