Re: strange ping and traceroute results

[Michael Tewner]

Heh - You _learn_ that Anycast isn't good for TCP, but LinkedIn proved
differently. Their website uses TCP (obviously), works almost always, and
gracefully recovers when Anycast throws a curve.

There's a great interview on Packet Pushers with LinkedIn Global
Engineering:

Packet Pushers: Show 286: Busting Anycast TCP Myths
http://packetpushers.net/podcast/podcasts/show-286-busting-anycast-tcp-myths/

...and a blog post:
https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality

-Mike Tewner



On Fri, Nov 25, 2016 at 12:14 AM, Amos Shapira 
wrote:

> Anycast is not suitable for TCP.
> It IS fantastic for DNS (which uses UDP), which is the first thing a
> client does most of the time to find the server.
> Akamai control server groups by allocating per-customer per-object host
> names, then these can be resolved using their very highly customised DNS
> servers to the right server (also taking into account dynamic changes like
> server cluster load or failure).
> Since DNS uses UDP and the traffic consists on one packet in each
> direction, Anycast is ideal for that scenario.
> The actual content transfer (e.g. move streams, which is where I with
> Akamai for stan.com.au) doesn't use Anycast.
>
> On 24 November 2016 at 04:06, Shachar Shemesh  wrote:
>
>> On 22/11/16 02:19, Amos Shapira wrote:
>>
>> On 21 November 2016 at 18:20, Shachar Shemesh 
>> wrote:
>>
>>> The DNS resolving google.com guesses your gegraphical location, and
>>> gives you an answer that is nearest where you are. If you use another DNS
>>> to query the domain, you will get a different IP:
>>>
>>
>> It's not always a "guess your geographic location". The smarter ones use
>> Anycast to advertise the same IP address from multiple locations on the
>> Internet and let BGP do its magic to route your packets to the nearest
>> server, taking into account any congestion or other transient connection
>> speed changes. This is how Google's DNS 8.8.8.8 works, or Akamai's CDN. The
>> nice thing about it is that you get optimal response even at the host
>> resolution stage. The DNS server can then take its knowledge of the DNS
>> query source address into account when it decides which IP address to
>> resolve to.
>>
>> It's pretty neat, personally I find it a fascinating trick:
>> https://en.wikipedia.org/wiki/Anycast
>>
>> It is, quite fascinating. It is not, unfortunately, as useful as you make
>> it out to be. Neither Google nor Akamai use it for web traffic, for example.
>>
>> The reason is twofold. First, anycast is poorly equipted to handle TCP
>> connections. There is a (remote) possibility that the handler of your IP
>> would change mid-request, which would not play nice with your connection.
>>
>> The second, more pertinent, reason is that , at least for Akamai, they
>> would like to be able to control which server you reach when you make a
>> request. The would like to be able to re-route your in case something bad
>> happens to that server. DNS TTL can be set as low as 30 or 60 seconds. BGP
>> routes have much longer settle times.
>>
>> Shachar
>>
>
>
>
> --
> 
>
> ___
> Linux-il mailing list
> Linux-il@cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Amos Shapira]

Anycast is not suitable for TCP.
It IS fantastic for DNS (which uses UDP), which is the first thing a client
does most of the time to find the server.
Akamai control server groups by allocating per-customer per-object host
names, then these can be resolved using their very highly customised DNS
servers to the right server (also taking into account dynamic changes like
server cluster load or failure).
Since DNS uses UDP and the traffic consists on one packet in each
direction, Anycast is ideal for that scenario.
The actual content transfer (e.g. move streams, which is where I with
Akamai for stan.com.au) doesn't use Anycast.

On 24 November 2016 at 04:06, Shachar Shemesh  wrote:

> On 22/11/16 02:19, Amos Shapira wrote:
>
> On 21 November 2016 at 18:20, Shachar Shemesh  wrote:
>
>> The DNS resolving google.com guesses your gegraphical location, and
>> gives you an answer that is nearest where you are. If you use another DNS
>> to query the domain, you will get a different IP:
>>
>
> It's not always a "guess your geographic location". The smarter ones use
> Anycast to advertise the same IP address from multiple locations on the
> Internet and let BGP do its magic to route your packets to the nearest
> server, taking into account any congestion or other transient connection
> speed changes. This is how Google's DNS 8.8.8.8 works, or Akamai's CDN. The
> nice thing about it is that you get optimal response even at the host
> resolution stage. The DNS server can then take its knowledge of the DNS
> query source address into account when it decides which IP address to
> resolve to.
>
> It's pretty neat, personally I find it a fascinating trick:
> https://en.wikipedia.org/wiki/Anycast
>
> It is, quite fascinating. It is not, unfortunately, as useful as you make
> it out to be. Neither Google nor Akamai use it for web traffic, for example.
>
> The reason is twofold. First, anycast is poorly equipted to handle TCP
> connections. There is a (remote) possibility that the handler of your IP
> would change mid-request, which would not play nice with your connection.
>
> The second, more pertinent, reason is that , at least for Akamai, they
> would like to be able to control which server you reach when you make a
> request. The would like to be able to re-route your in case something bad
> happens to that server. DNS TTL can be set as low as 30 or 60 seconds. BGP
> routes have much longer settle times.
>
> Shachar
>



-- 

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Shachar Shemesh]

On 22/11/16 02:19, Amos Shapira wrote:
> On 21 November 2016 at 18:20, Shachar Shemesh  > wrote:
>
> The DNS resolving google.com  guesses your
> gegraphical location, and gives you an answer that is nearest
> where you are. If you use another DNS to query the domain, you
> will get a different IP:
>
>
> It's not always a "guess your geographic location". The smarter ones
> use Anycast to advertise the same IP address from multiple locations
> on the Internet and let BGP do its magic to route your packets to the
> nearest server, taking into account any congestion or other transient
> connection speed changes. This is how Google's DNS 8.8.8.8 works, or
> Akamai's CDN. The nice thing about it is that you get optimal response
> even at the host resolution stage. The DNS server can then take its
> knowledge of the DNS query source address into account when it decides
> which IP address to resolve to.
>
> It's pretty neat, personally I find it a fascinating trick:
> https://en.wikipedia.org/wiki/Anycast
>
It is, quite fascinating. It is not, unfortunately, as useful as you
make it out to be. Neither Google nor Akamai use it for web traffic, for
example.

The reason is twofold. First, anycast is poorly equipted to handle TCP
connections. There is a (remote) possibility that the handler of your IP
would change mid-request, which would not play nice with your connection.

The second, more pertinent, reason is that , at least for Akamai, they
would like to be able to control which server you reach when you make a
request. The would like to be able to re-route your in case something
bad happens to that server. DNS TTL can be set as low as 30 or 60
seconds. BGP routes have much longer settle times.

Shachar
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Amos Shapira]

On 21 November 2016 at 18:20, Shachar Shemesh  wrote:

> The DNS resolving google.com guesses your gegraphical location, and gives
> you an answer that is nearest where you are. If you use another DNS to
> query the domain, you will get a different IP:
>

It's not always a "guess your geographic location". The smarter ones use
Anycast to advertise the same IP address from multiple locations on the
Internet and let BGP do its magic to route your packets to the nearest
server, taking into account any congestion or other transient connection
speed changes. This is how Google's DNS 8.8.8.8 works, or Akamai's CDN. The
nice thing about it is that you get optimal response even at the host
resolution stage. The DNS server can then take its knowledge of the DNS
query source address into account when it decides which IP address to
resolve to.

It's pretty neat, personally I find it a fascinating trick:
https://en.wikipedia.org/wiki/Anycast

--Amos
-- 

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Shachar Shemesh]

On 20/11/16 07:01, Shlomo Solomon wrote:
> When I try ping or traceroute to www.google.com, I get strange results.
> Both utilities "think" that www.google.com is at 213.57.*.*, but those
> addresses belong to my Internet provider - Hotnet.
>
> What am I missing?
>
> [solomon@shlomo1]$ ping www.google.com
> PING www.google.com (213.57.23.29) 56(84) bytes of data.
> 64 bytes from 213.57.23.29: icmp_seq=1 ttl=59 time=17.1 ms
> 64 bytes from 213.57.23.29: icmp_seq=2 ttl=59 time=16.8 ms
> 64 bytes from 213.57.23.29: icmp_seq=3 ttl=59 time=17.1 ms
>
> [solomon@shlomo1]$ sudo traceroute www.google.com
> traceroute to www.google.com (213.57.24.55), 30 hops max, 60 byte packets 
> 1  router-1.solomon (10.0.0.138)  1.010 ms  1.007 ms  1.006 ms
> 2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.379 ms  15.741 ms  
> 16.551 ms 
> 3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 36.177 ms  36.182 ms  
> 36.178 ms 
> 4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.736 ms  17.736 ms  
> 17.733 ms 
The DNS resolving google.com guesses your gegraphical location, and
gives you an answer that is nearest where you are. If you use another
DNS to query the domain, you will get a different IP:


216.58.218.196 from
http://mxtoolbox.com/SuperTool.aspx?action=a%3awww.google.com=toolpage
74.125.22.103 from https://www.ultratools.com/tools/dnsLookupResult
216.58.209.68 from http://ping.eu/nslookup/

If you are dead set on using a different IP than your local one, you can
use this trick to do this.

Shachar
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Shlomo Solomon]

On Sun, 20 Nov 2016 10:18:37 +0200
shimi  wrote:

Thanks for your very detailed reply. As you correctly assumed, I did
learn about traceroute before re-inventing the wheel, so most of what
you wrote was familiar. But I didn't know about the -I parameter.
 
traceroute -I www.google.com does, as you wrote, get to the target. 

Since I think that that's more than I'm expected to emulate, I
added a more "friendly" error message to my program in the case of a
(FW caused) timeout.




-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5


___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Amos Shapira]

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  wrote:

>
>
> On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon 
> wrote:
>
>> On Sun, 20 Nov 2016 08:25:18 +0200
>> shimi  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
> Linux-il@cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>


-- 

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[shimi]

On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon 
wrote:

> On Sun, 20 Nov 2016 08:25:18 +0200
> shimi  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
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Shlomo Solomon]

On Sun, 20 Nov 2016 08:25:18 +0200
shimi  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




[solomon@shlomo1 ~]$ sudo traceroute www.godaddy.com
traceroute to www.godaddy.com (23.44.253.116), 30 hops max, 60 byte
packets 
1  router-1.solomon (10.0.0.138)  0.610 ms  0.979 ms  0.977 ms
2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.370 ms  15.753
ms  16.148 ms 
3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 16.544 ms
16.543 ms  16.553 ms 
4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.345 ms
18.132 ms  18.524 ms 
5  207.232.21.146 (207.232.21.146)  20.941 ms  20.948 ms  20.944 ms 
6 core1-TenGigE0-4-0-1.hfa.nv.net.il (212.143.8.226)  21.311 ms
core1-0-5-0-21-edge1.hfa.nv.net.il (212.143.7.173)  22.651 ms  22.379 ms 
7  cdn-sw1-1-35-core1-2-5-hfa.hfa.nv.net.il (212.143.7.252)  21.129 ms
cdn-sw1-1-45-core1.hfa.nv.net.il (212.143.7.209)  18.333 ms 
cdn-sw1-1-43-core1.hfa.nv.net.il (212.143.7.201)  19.097 ms 
8 a23-44-253-116.deploy.static.akamaitechnologies.com (23.44.253.116)
18.299 ms  18.290 ms  18.703 ms



[solomon@shlomo1 ~]$ sudo traceroute www.google.com
traceroute to www.google.com (213.57.24.49), 30 hops max, 60 byte
packets 
1 router-1.solomon (10.0.0.138)  0.943 ms  0.937 ms  0.934 ms 
2 core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.313 ms  15.720 ms
16.114 ms 
3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 16.128 ms
16.526 ms  16.526 ms 
4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  21.311 ms
21.692 ms  21.675 ms 
5  * * * 
6  * * * 
7  * * * 
8  * * * 
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[solomon@shlomo1 ~]$ 



-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5


___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[shimi]

On 20 Nov 2016 07:02, "Shlomo Solomon"  wrote:
>
> When I try ping or traceroute to www.google.com, I get strange results.
> Both utilities "think" that www.google.com is at 213.57.*.*, but those
> addresses belong to my Internet provider - Hotnet.
>
> What am I missing?
>
> [solomon@shlomo1]$ ping www.google.com
> PING www.google.com (213.57.23.29) 56(84) bytes of data.
> 64 bytes from 213.57.23.29: icmp_seq=1 ttl=59 time=17.1 ms
> 64 bytes from 213.57.23.29: icmp_seq=2 ttl=59 time=16.8 ms
> 64 bytes from 213.57.23.29: icmp_seq=3 ttl=59 time=17.1 ms
>
> [solomon@shlomo1]$ sudo traceroute www.google.com
> traceroute to www.google.com (213.57.24.55), 30 hops max, 60 byte packets
> 1  router-1.solomon (10.0.0.138)  1.010 ms  1.007 ms  1.006 ms
> 2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.379 ms  15.741 ms
16.551 ms
> 3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 36.177 ms  36.182
ms  36.178 ms
> 4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.736 ms  17.736
ms  17.733 ms
> 5  * * *
> 6  * * *
> 7  * * *
> 8  * * *

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).

There are other similar POPs I saw at least in BezeqInt.

The question really is:

Why do you think it's a problem and are trying to avoid it?

If your reply includes the letters M-I-T-M, please consider that without
installing a fake CA cert on your host, MITMing an SSL/TLS connection WILL
cause a connection set up error from your browser.

HTH,

-- Shimi
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Shlomo Solomon]

Thanks. Any way to get around this? 
I just tried pinging Google-UK (www.google.co.uk) and Google-Canada
(www.google.ca) and I see the same behaviour.



On Sun, 20 Nov 2016 05:13:29 +
Geoffrey Mendelson  wrote:

> Google.com resolves to addresses routed to Google.co.il and 8.8.4.4
> and 8.8.8.8 are routed to a local nameserver.
> 
> It is all part of a local cache system.
> 
> Geoff.
> 
> On Sun, Nov 20, 2016, 07:02 Shlomo Solomon 
> wrote:
> 
> > When I try ping or traceroute to www.google.com, I get strange
> > results. Both utilities "think" that www.google.com is at
> > 213.57.*.*, but those addresses belong to my Internet provider -
> > Hotnet.
> >
> > What am I missing?
> >
> > [solomon@shlomo1]$ ping www.google.com
> > PING www.google.com (213.57.23.29) 56(84) bytes of data.
> > 64 bytes from 213.57.23.29: icmp_seq=1 ttl=59 time=17.1 ms
> > 64 bytes from 213.57.23.29: icmp_seq=2 ttl=59 time=16.8 ms
> > 64 bytes from 213.57.23.29: icmp_seq=3 ttl=59 time=17.1 ms
> >
> > [solomon@shlomo1]$ sudo traceroute www.google.com
> > traceroute to www.google.com (213.57.24.55), 30 hops max, 60 byte
> > packets 1  router-1.solomon (10.0.0.138)  1.010 ms  1.007 ms  1.006
> > ms 2  core-213-57-3-7.ptr.hotnet.net.il (213.57.3.7)  15.379 ms
> > 15.741 ms 16.551 ms
> > 3  ae7.101.hfa.mx-lns.con.hotnet.net.il (213.57.3.221) 36.177 ms
> > 36.182 ms  36.178 ms
> > 4  core-213-57-3-217.ptr.hotnet.net.il (213.57.3.217)  17.736 ms
> > 17.736 ms  17.733 ms
> > 5  * * *
> > 6  * * *
> > 7  * * *
> > 8  * * *
> >
> >
> > --
> > Shlomo Solomon
> > http://the-solomons.net
> > Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5
> >
> >
> > ___
> > Linux-il mailing list
> > Linux-il@cs.huji.ac.il
> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
> >



-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5


___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Shlomo Solomon]

This seems to be specific to www.google.com. Other addresses work as
expected.

Trailing dot does not change anything.

On Sun, 20 Nov 2016 05:15:04 +
Daniel Shahaf  wrote:

> Shlomo Solomon wrote on Sun, Nov 20, 2016 at 07:01:10 +0200:
> > When I try ping or traceroute to www.google.com, I get strange
> > results. Both utilities "think" that www.google.com is at
> > 213.57.*.*, but those addresses belong to my Internet provider -
> > Hotnet.
> > 
> > What am I missing?
> > 
> 
> Try with a trailing dot?
> 
> % ping www.google.com.
> 
> 
> Try other domains?
> 
> % ping www.$(pwgen).com



-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.14.5 - LINUX Mageia 5


___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: strange ping and traceroute results

[Daniel Shahaf]

Shlomo Solomon wrote on Sun, Nov 20, 2016 at 07:01:10 +0200:
> When I try ping or traceroute to www.google.com, I get strange results.
> Both utilities "think" that www.google.com is at 213.57.*.*, but those
> addresses belong to my Internet provider - Hotnet.
> 
> What am I missing?
> 

Try with a trailing dot?

% ping www.google.com.


Try other domains?

% ping www.$(pwgen).com

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il