Re: strange ping and traceroute results

Google.com is not one computer. Google spreads their locations all over the
world including pops in many ISP's.

https://peering.google.com/#/

On 20 November 2016 at 19:18, shimi <[email protected]> wrote:

>
>
> On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon <[email protected]>
> wrote:
>
>> On Sun, 20 Nov 2016 08:25:18 +0200
>> shimi <[email protected]> wrote:
>>
>> > I believe it's called a CDN and/or local compute clusters and the
>> > purpose of it is to give you a better user experience, which is a
>> > Good Thing (TM).
>> >
>> snip ... snip ... snip
>> >
>> > Why do you think it's a problem and are trying to avoid it?
>> >
>>
>> Thanks. I agree that this is "normally" a Good Thing (TM). So I guess I
>> have to explain my problem. For a course I'm doing, I had to write
>> traceroute in Python   -   re-invent the wheel :-)
>>
>> My program works, but I noticed it never reaches www.google.com so I
>> checked the "real" traceroute and found the same behaviour.
>>
>> It seems that neither my program nor the real traceroute handle this
>> properly - i.e. they never report that they've reached the final hop.
>> I've included traceroute www.godaddy.com and traceroute www.google.com
>> for comparison. You can see that traceroute www.google.com never
>> reaches the address it's trying to reach - 213.57.24.49
>>
>>
> I do not believe the fact that you "can't reach it" has anything to do
> with www.google.com resolving to an IP in Israel.
>
> Since I am assuming that for your re-inventing the wheel exercise, you did
> learn and understood what traceroute does; But let me explain it anyway for
> the answer to your question lies within...
>
> What traceroute does is essentially send packets to the destination IP by
> certain protocol. Popular choices include UDP (I believe that's what the
> Linux one does by default), ICMP (I believe that's what the Windows one
> does by default) and TCP.
>
> However, it doesn't send the packet as one normally would, with a large
> TTL (Time To Live) value which is expected to reach anywhere on the
> Internet (typical values: >= 64), rather than it starts of with setting a
> minimal value for TTL, for the purpose of _not_ getting into the target IP,
> rather than the packet being dropped by the very first router (hop) on the
> chain, resulting in error in packet  delivery.
>
> Per the IP specification, such a packet discarding SHOULD produce an ICMP (Internet
> Control Message Protocol) message being sent by the hop that has discarded
> the packet towards the originator of the original packet, telling it that
> "TTL expired in transit". The original idea was to avoid packets travelling
> to infinitum in routing loops - by decreasing the TTL by 1 on every hop the
> packet passes, eventually it will zero out, and the packet will be
> discarded, not causing a bandwidth storm.
>
> So, I said SHOULD. Does it always? Well, no. Some hosts on the Internet
> employ something called "a firewall", which blocks ICMP for various reasons
> (you'll hear the word "security" in some places); As a regular user who
> opens his browser and types in 'https://www.google.com/' - you don't
> really care. ICMP is not typically used when establishing a connection to a
> server on the Internet (well, that's not accurate; lack of PMTU discovery
> is an excellent way to get your IT people to pull some hairs out when any
> tunnel is involved, including dialup and Israeli "MPLS" connections, a.k.a.
> "dialer-less HOT"... but for the sake of discussion and to explain how did
> they ended up deciding to filter those packets and affect you - probably
> not knowing what else they break - then "it's not typically used")
>
> Sometimes the filtering is not of ICMP at all, rather than the original
> protocol you're trying to probe with; A random UDP port at the area of
> 30,000 typically has no business traversing their network, so your original
> packet (if you're using UDP packets for your traceroute program) may have
> been firewalled and never reached a router to lower its TTL by 1 and expire
> it in transit to produce the ICMP message you're expecting... In that case,
> where ICMP is not actually block, rather your UDP connection is, you might
> find out that running:
>
> traceroute -I 213.57.24.49
>
> (I for ICMP Echo based traceroute)
>
> Does actually get you to the target. However, you'll have to run this as
> root, because generating ICMP packets is not something the regular user can
> do. Of course, you can opt to chmod +s your traceroute binary...
>
> Hope this helps,
>
> -- Shimi
>
>
>
> _______________________________________________
> Linux-il mailing list
> [email protected]
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>


-- 
<http://au.linkedin.com/in/gliderflyer>

_______________________________________________
Linux-il mailing list
[email protected]
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il