13

Two of my servers can't contact the Stack Exchange Network, namely my buddies tin.gparent.org (96.47.226.60) and titanium.gparent.org (96.47.230.94). One of my other VPSes, steel.gparent.org (106.186.17.181), can ping SE fine. I can also ping fine from Eastern Canada (both at work and at home), and one of my friends in Europe confirmed pings both from his location and from a VPS in Germany.

Traceroutes end up at SE's doorstep, 64.34.60.18.

I contracted Peer 1 and they tell me everything is fine. I've never used the site's API, and as far as I know I haven't been abusive in any way.

I sent an email to [email protected], however this is the kind of problem that may signify an outage or malfunction of some sort and it seemingly affects a subnet so I felt appropriate to ask here.

Traceroute:

gp@tin:~$ traceroute serverfault.com
traceroute to serverfault.com (64.34.119.12), 30 hops max, 60 byte packets
 1  172.18.13.130 (172.18.13.130)  0.026 ms  0.013 ms  0.011 ms
 2  173.44.32.249 (173.44.32.249)  0.301 ms  0.358 ms  0.408 ms
 3  te2-3.ccr01.mia05.atlas.cogentco.com (38.122.220.1)  0.753 ms  0.837 ms  0.920 ms
 4  te2-7.ccr01.mia08.atlas.cogentco.com (154.54.83.145)  8.801 ms te2-8.ccr01.mia08.atlas.cogentco.com (154.54.83.149)  8.950 ms te2-7.ccr01.mia08.atlas.cogentco.com (154.54.83.145)  9.067 ms
 5  te8-3.ccr01.mia01.atlas.cogentco.com (154.54.83.17)  0.562 ms te9-3.ccr01.mia01.atlas.cogentco.com (154.54.83.21)  0.649 ms  0.679 ms
 6  te4-8.ccr01.mia03.atlas.cogentco.com (154.54.3.126)  0.565 ms te4-7.ccr01.mia03.atlas.cogentco.com (154.54.28.246)  0.567 ms te8-1.ccr02.mia01.atlas.cogentco.com (154.54.40.74)  0.446 ms
 7  te4-1.ccr02.mia03.atlas.cogentco.com (154.54.47.70)  0.680 ms  0.589 ms  0.626 ms
 8  ge-7-4.car2.Atlanta1.Level3.net (4.68.110.161)  0.448 ms ge-7-6.car2.Atlanta1.Level3.net (4.68.110.169)  0.472 ms ge-7-4.car2.Atlanta1.Level3.net (4.68.110.161)  0.481 ms
 9  ae-32-52.ebr2.Miami1.Level3.net (4.69.138.123)  0.532 ms  0.458 ms  0.433 ms
10  ae-2-2.ebr2.Atlanta2.Level3.net (4.69.140.142)  21.493 ms  21.545 ms  18.898 ms
11  ae-1-100.ebr1.Atlanta2.Level3.net (4.69.132.33)  24.086 ms  13.937 ms  14.075 ms
12  ae-6-6.ebr1.Washington12.Level3.net (4.69.148.106)  28.529 ms  28.377 ms  28.454 ms
13  ae-1-100.ebr2.Washington12.Level3.net (4.69.143.214)  28.158 ms  34.205 ms  34.740 ms
14  4.69.148.49 (4.69.148.49)  31.682 ms  31.515 ms  31.772 ms
15  ae-91-91.csw4.NewYork1.Level3.net (4.69.134.78)  35.751 ms ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66)  31.719 ms  31.721 ms
16  ae-3-80.edge1.NewYork1.Level3.net (4.69.155.142)  31.694 ms ae-1-60.edge1.NewYork1.Level3.net (4.69.155.14)  31.662 ms  31.806 ms
17  * * *
18  gig2-0.nyc-gsr-b.peer1.net (216.187.123.5)  31.901 ms  31.750 ms  31.600 ms
19  64.34.60.18 (64.34.60.18)  32.316 ms  32.002 ms  32.129 ms
20  * * *
[...]
30  * * *
gp@tin:~$

UPDATE: The RFC1918 hop is no longer present in the topology, however the answer below shows it was not a network problem.

Improve this question
4
  • Can you please clarify the question: Do your servers have public IP addresses on their network interfaces, or private (RFC 1918) addresses?
    – Michael Hampton
    Commented Oct 25, 2012 at 3:57
  • All of my servers have publicly addressable IPs on their network interfaces.
    – gparent
    Commented Oct 25, 2012 at 3:58
  • Hi @gparent, I've adjusted the ban range which should permit you to access serverfault again.
    – Peter Grace
    Commented Oct 27, 2012 at 16:24
  • Hi, thanks Peter. Did you see the exact network blocks in chat? If not they should be archived. Thanks again for your help.
    – gparent
    Commented Oct 28, 2012 at 2:54

2 Answers 2

Reset to default
30

Your VPS's are hosted at QuadraNet/IPTelligent which is currently banned due to excessive blogspam. I e-mailed both providers and asked them to intercede, but they have ignored the request. The IP addresses will remain banned until they've reported that they've taken corrective action.

Improve this answer
9

This looks like a problem with the network where your servers are hosted. They have used RFC 1918 addresses on their router on a public network, a huge no-no.

 1  172.18.13.130 (172.18.13.130)  0.026 ms  0.013 ms  0.011 ms

Among other things, this causes Path MTU discovery to break, which means many TCP connections will also break.

To quote from one source, Cisco's IP Addressing Best Practices (PDF):

Any router-to-router links connecting to areas of the network with public addressing should be addressed with public IP addresses. Routers serving specific areas of the network using and continuing to use only private addresses may use private addresses on the router-to-router links.

This requirement enables and helps ensure that path MTU discovery (RFC 1191) works properly; routers must be able to send "packet-too-big" errors and must be assured that the packets are likely to arrive at the original source host. If router-to-router links are addressed with RFC 1918 addresses, the Internet Control Message Protocol (ICMP) messages generated by the router will come from an RFC 1918 address. Networks filtering out incoming packets with RFC 1918 source IP addresses, or using unicast reverse path forwarding (uRPF), will likely drop these packets, breaking TCP for those applications. This will cause large packet transfer across a TCP connection to fail completely or perform suboptimally.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .