Connectivity Issues Update
12 years ago
🏳️🌈💖Enjoy the site? Please consider supporting us via the links below!💖🏳️🌈
⭐ FA+ ⭐ SHOP ⭐ KO-FI ⭐
Journal Start
Following up to our last journal, we believe we have narrowed down the issues with site connectivity for select users. The problem appears to have been a DNS issue on our host's side. Somehow, one of our IPs was issued out to another site via the DNS PTR records, and the conflict caused some issues for certain users. We discussed the issue with our site's host and they made changes this morning to try to rectify the problem.
Many of the users reporting connection issues have contacted us saying that their connection issues have been resolved. For others still experiencing problems it can take up to 24 hours for the full DNS changes to propagate. If you're still having access issues by tomorrow please let us know as we're continuing to investigate things on our side.
Many of the users reporting connection issues have contacted us saying that their connection issues have been resolved. For others still experiencing problems it can take up to 24 hours for the full DNS changes to propagate. If you're still having access issues by tomorrow please let us know as we're continuing to investigate things on our side.
FA+



*.facdn.net is a wildcard, that resolves to 70.33.186.221 for everyone. It has worked off and on for the last few days - getting upwards of 90% packet loss at times.
The failure is
16 CWIE-LLC.car2.Washington1.Level3.net (4.59.156.58) 52.429 ms 48.219 ms 52.867 ms
17 cr2.iad3.inforelay.net (70.33.180.254) 53.564 ms 49.705 ms 53.515 ms
18 cr2.iad2.inforelay.net (67.208.89.118) 50.151 ms 47.644 ms 55.127 ms
19 cr2.iad2.inforelay.net (67.208.89.118) 50.564 ms !X * *
And IP routing has nothing to do with DNS.
;; AUTHORITY SECTION:
facdn.net. 172800 IN NS ns95.worldnic.com.
facdn.net. 172800 IN NS ns96.worldnic.com.
harik@wolf:~$ dig d.facdn.net ns96.worldnic.com
;; ANSWER SECTION:
d.facdn.net. 7200 IN A 70.33.186.221
Can we get a straight answer that doesn't involve trying to bamboozle people with buzzwords? The intermittent downtime is completely incompatible with your answer of a DNS error - especially with a 2 hour refresh on your A record. PTRs are used for reverse DNS and don't impact attempting to connect to your site - although they are frequently used as authoratative in IP allocation.
Still, it doesn't explain why www.FA.N (hosted on the same subnet) works while *.facdn.net is unreachable. That screams some sort of hardware problem, not "*coughmumbleDNScough*"
Smells like a routing loop to me.
not only that, but I still don't see why an IP would be randomly issued to someone else if one person has it first. especially if that person has had it for (months? years?)
Also it is good thar people question the authenticity of what companies or individuals are shoving down their throats.
harik's response makes sense while FA's sadly doesn't. Or at least, FA's response looks confused. It might satisfy people who wouldn't understand this stuff but it doesn't satisfy those of us that do. It's probably not intended to be deceitful, but as it's written, it just doesn't give any meaningful information or even make sense.
DNS PTR records have absolutely nothing to do with accessing a website. In simple terms, DNS maps domain names to machine IP addresses. When you visit an address, your browser does a 'forward lookup', asking for an IP address from a name, so your browser knows where to connect to. Certainly, if DNS is broken in such a way that forward lookups fail, things stop working (although when things break this way, most people will see a message which hints at the problem very quickly, something to the effect of website can't be found or doesn't exist).
You can also go the other way - looking up a name from an IP address. This is the much lesser used-or-cared-about 'reverse DNS' and this is what the PTR ("pointer") records are all about. While some services often depend on reverse DNS working (such as email), ordinary websites do not. Anyone at FA in a position to change a PTR record can put it any name they wish. They can make all FA's IP addresses reverse-resolve to microsoft.com - and it wouldn't matter. PTR records just don't matter here. Nobody will notice unless they really go looking. Similarly there can be no PTR record at all. That's just fine. Email may break, but not the site.
So to mention any problem with PTR records and suggest that a DNS change fixes this as it might with a 'regular' forward DNS screwup... is nonsense. Most people won't know it. Some of us do. We're not special. We just do this stuff for a living.
I suspect somebody somewhere has their wires crossed, figuratively, or there's been a case of Chinese whispers. There's also mention of an IP conflict which is much more interesting. It MIGHT be that somebody other than FA have screwed up, and some of FA's IP's have been duplicated elsewhere. Maybe their ISP poorly manages them, and the DNS thing itself has nothing to do with it but could have been a symptom. I might expect very bad things to happen if some sort of IP conflict has occurred. If, say, somebody else has been able to update DNS PTR records for FA's IPs, that means somebody else may well have been provisioned those IPs as well, and that would be the real problem (in that scenario, DNS PTR record changes are a symptom, not a cause of a problem). At the moment that's the most sense I can make of it, based only on what FA and a few other people have said.
Or maybe FA's admins have been completely bullshitted to by their ISP, and themselves told of something or other involving DNS and PTR records, and relayed some already misunderstood message to us. I'd really hope that isn't the case though, but what we have been given, as it reads now, is basically nonsense.
It's also entirely possible something else has broken at the same time, and is being overlooked. Simultaneous failures can and do happen from time to time, and it can be easy to fixate on one cause - especially if somebody else like an ISP has given some sort of explanation already.
Curiously although FA is probably among the worst sites on the web for a vast list of reasons, it's been working absolutely fine for me during this whole incident.
I'd like to prove how wrong you are, but I don't have the time or the motivation to go searching the web for badly designed, immoral, or overall horrible web sites.
The combination of network range and PTR record is used by some automatic configuration systems. Without knowing more about their setup, we can't say this conclusively.
There does appear to be some other issue at play, but the pile on where some folks are calling the admins liars or incompetent isn't warranted based on as much information as has been presented here.
~ That guy who works for a major networking company.
Off topic, what distro?
I think that while FA may not be the best site out there, I prefer its simple design (though a few features could be added) and I appreciate that the FA admins are looking into the problem. Whether or not they've found it is another story. Only time will tell.
Perhaps some people DO know more about what's been happening, but I sure don't. All I know is that it had to be something between the affacted users and the site itself, because I wasn't experiencing these problems, along with many others.
but... it's still in like 2006 and older in terms of coding. it's really outdated and it needs a major makeover, things would stop breaking less if they just tore it down and rebuilt it or did something other than overlapping old code with new code but still probably breaking things in the process by doing that- i'm sure you've heard it all before so i won't really get into it
just.. try to not assume the fa admins are the only people that know this stuff- there are IT people and hell, computer geniuses that know a lot more than the admins do and i'm willing to believe there are users on fa who are more experienced. i've witnessed it myself when i've had to ask some people on fa for help regarding my computer so it's not impossible that these folks know what they're talking about u3u
given fa's history i wouldn't doubt they don't really know what's going on either, like the person above said maybe their provider is dicking them around or something who knows but still... that's no reason to doubt others like that!
His dig shows the current status of DNS, but tells us nothing about the previous state. The old configuration could well have had a very long TTL even if the current one is measured in hours. So there's no conclusive proof that the original post was not believed as true when it was written.
However, the intermittency that persists for some users (as per the many replies below) and the traceroute results some have shared suggest that there is a separate problem that has not yet been acknowledged by admins.
Assuming they run linux with apache for their servers, I think the problem might lie within their apache configuration file. That would explain why one part of the site works, but another doesn't.
DNS records do factor into website issues. Specifically A Records and aliases to A Records whose name eludes me at this time. The aliases, however, have to be configured in the apache configuration to even work. Otherwise they will automatically redirect to the www subdomain.
My advice to FA dev team: check the DNS records and the apache configuration in /etc/httpd/conf.clients, make sure the IP addresses match up, use the dig command to double check everything.
And we are looking into the connectivity issues across the board, trying to determine the root source. We had thought it may have been an issue with that at first. We're trying to rule out the problem.
16 CWIE-LLC.car2.Washington1.Level3.net (4.59.156.58) 46.963 ms 45.645 ms 48.080 ms
17 cr2.iad3.inforelay.net (70.33.180.254) 55.048 ms 51.986 ms 56.364 ms
18 cr2.iad2.inforelay.net (67.208.89.118) 52.598 ms 48.561 ms 51.073 ms
19 * * *
20 * * *
vs
16 CWIE-LLC.car2.Washington1.Level3.net (4.59.156.58) 46.393 ms 45.769 ms 46.324 ms
17 cr2.iad3.inforelay.net (70.33.180.254) 52.657 ms 51.315 ms 50.695 ms
18 cr2.iad2.inforelay.net (67.208.89.118) 47.107 ms 50.038 ms 47.777 ms
19 66.231.180.84 (66.231.180.84) 53.959 ms 51.660 ms 52.934 ms
20 www.furaffinity.net (70.33.186.196) <syn,ack> 54.957 ms 53.223 ms 52.504 ms
See hop 19? That's where shit goes wrong. That's not DNS related. Furafinity.net hasn't changed IP addresses between those runs, it's always at .186.196. If I had to speculate, .180.84 is either a router or load balancer with a flakey port, and someone with access to it can check it's logs and watch traffic on the port connecting to cr2.iad2.
Why are you still faffing on about DNS?
Oh man.Well we will see how this goes down over the weekend.
traceroute to www.furaffinity.net (70.33.186.196), 30 hops max, 60 byte packets
...
14 ae-32-80.car2.Washington1.Level3.net (4.69.149.132) 31.338 ms 37.386 ms ae-42-90.car2.Washington1.Level3.net (4.69.149.196) 36.510 ms
15 CWIE-LLC.car2.Washington1.Level3.net (4.59.156.58) 34.242 ms 35.765 ms 34.891 ms
16 cr2.iad3.inforelay.net (70.33.180.254) 36.945 ms 37.323 ms 36.759 ms
17 cr2.iad2.inforelay.net (67.208.89.118) 35.934 ms 37.606 ms 37.699 ms
18 cr2.iad2.inforelay.net (67.208.89.118) 37.259 ms !X * *
It's like this off and on all day, cr2.iad2.inforelay.net is always the failure point. None of my testpoints trace to you through any other path, so I'm not sure how it's working for you guys. !X is "Communication administratively prohibited" so probably losing it's route and dropping your subnet into the bitbucket.
When it works it has two more hops:
19 66.231.180.84 38ms
20 www.furaffinity.net (70.33.186.196) 29ms
Tracing from a working location goes through the following:
13. cr2.iad1.inforelay.net 0.5% 378 29.6 35.9 28.2 216.5 28.2
14. cr1.iad2.inforelay.net 0.5% 378 28.9 35.6 28.3 236.7 26.4
15. 66.231.180.84 0.0% 378 30.0 30.0 28.3 34.2 0.9
16. www.furaffinity.net 0.0% 378 29.2 29.3 28.3 32.0 0.6
Note it's a slightly different set of routers - cr2.iad1->cr1.iad2 vs cr2.iad3->cr2.iad2.
cr2.iad2 is extremely broken and you need to yell at your provider until they fix it.
Other people backed up what you're saying in the previous journal and it went unanswered.
You don't say...
http://stats.pingdom.com/q77gc3euyn6b/169836
Technically inclined people really need to stop barking at users for being stupid. FA is slow during USA daylight hours. This is no secret.
Even if the site is slow, even if it's poorly managed, it's not our site. We don't help run it, and aside from people buying ad space or donating we don't pay to keep it running. There is no membership fee, we're not on staff or buying hardware. We're not shareholders or investors either.
This site doesn't owe any of us anything, was more my point, and while companies and individuals rely on constructive user imput to resolve issues and make improvements, that is very different from people constantly whining about how bad this site is when they're offering no help to fix it and have nothing to do with it's operation.
My response was directed at 'tone', not 'knowledge'.
http://habnab.it/fa/1year/
Thanks for getting it fixed guys :D
Besides, if another website's domain name got assigned your IP, the people going to that domain would just go to FA instead. That's how DNS works.
Will report as it further develops, unless it gets to the point that I can't even get on here.
Either way, I'm glad you guys are doing something about it, I'm sure it means a lot to some people. ^^
Still acting up as of this morning.
Works well one time, then stalls, then works again a few minutes later.
Hopefully the DNS will resolve soon.
Thank you for your support.
Your efforts are highly appreciated by this particular dragon.
Kindest regards;
}:>
PS: Took several attempts, and time outs, to submit this reply . . .
I dunno, but I have to agree with Harik on this, it doesn't sound like a DNS issue. If anything, I think it may be some sort of hardware or software configuration / glitch on server side, hardware that is faulty, or not responding correctly.
I mean, I'm even noticing longer load times even when the site is up and running for me, and I have FiOS (50 Mbit) internet speeds. I usually never see slow load times..
FA's page generation time for me though (whenever it works) is up to almost ".800" seconds. I usually have the page generate in under ".100". I even get almost ".800" under non-peak times of day, and even non-peak days too where people usually aren't on.
I'm starting to think something else may be the culprit, just my two cents.
"The connection has timed out
The server at www.furaffinity.net is taking too long to respond."
Works perfect for a while, then goes down for 10-15mins at a time
What do we learn?
Not just code needs debugging at times =)
Some advise - always keep your DNS in your eyes, it loves to get messed up, especially when you have a few NS providers.
How many of you FA-runners actually know how to handle DNS... :p
Just do this...erase all zone files, re-write them from scratch, period. :)
Im not respective for the site, I just am kinda amoused by how slow their fix-up is going... but then again, I never heared the FA team and the word "speed" or "fast" in the same sentence :p
You really don't know anything about anything, do you? Like, I couldn't reach the site to respond to you for a week and I come back and find that you weren't actually being satirical about DNS, you really think you know anything about it at all and that it had anything whatsoever to do with the outage.
Were you the retard who thought that it was a DNS issue because the MX records weren't right? Or was that some other technologically illiterate jackass who felt the need to open their piehole.
Check the most recent journal on this, then we talk again. :D
Hey shit for brains, explain what that has to do with DNS and MX records?
In fact had trouble even loading this journal, heh.
It was even a problem just to get this replay message posted to this journal.
Yes, I cleared my cache and cookies already.
But people please be patient.
Things have started working out for me btw.
Is some sort of routing protocol enabled? RIP or OSPF? Check the load on the ferrox router and see if it's pegged; same thing goes for the InfoRelay router that seems to be where the problem occurs. I would have hoped someone would have seen all of this though. Same goes for a router or interface going online and offline repeatedly. I don't know how many routers FA has or if there's just the one for all of the "ferrox" network.
I doubt it's a load balancer issue since some users never have the problem at all.
This is probably just pissing into the wind though since I doubt any admin will keep reading this far.
The connection has timed out
The server at www.furaffinity.net is taking too long to respond.
The site could be temporarily unavailable or too busy. Try again in a few
moments.
If you are unable to load any pages, check your computer's network
connection.
If your computer or network is protected by a firewall or proxy, make sure
that Firefox is permitted to access the Web.
fix this shit before i go to inkbunny
Also, making threats like "I'll go to inkbunny" is pretty moot. I'm sure they wont be crying themselves to sleep with a handful, let alone 1 person, walks off and frees up some space on they're hard-drives.
Location: jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/omni.ja!/chrome/toolkit/content/global/netError.xhtml
Line Number 305, Column 54: <div id="ed_netTimeout">&netTimeout.longDesc;</div>
^
This error comes up from time to time, instead of the 'standard' time-out these connection issues are causing. You guys still have stuff to fix.
An XML parsing error, on a local drive, could be some sort of addon you installed.
*sigh* I hope this gets fixed soon.
win+r > cmd> ipconfig /flushdns > ipconfig /registerdns
^= removes old entries and requestsa new mapout.
blahblah DNS blahblah -
no change at all - its still the same ip. there is no szenario where something can propagate to us which brakes traceroute SOMETIMES.
do you have a broken dns server which cannot resolve some of OUR ips and blocking those connections sometimes when the query times out? maybe you want do try a locally caching dns-server like dnsmasq.
(zone serial 113031910)
12 dca1.inforelay.net (208.173.12.130) 37.083 ms 34.144 ms 34.200 ms
13 cr2.iad3.inforelay.net (67.208.76.5) 23.454 ms 23.266 ms 23.174 ms
14 cr2.iad2.inforelay.net (67.208.89.118) 23.510 ms 23.584 ms 23.464 ms
15 cr2.iad2.inforelay.net (67.208.89.118) 23.551 ms !X * *
man traceroute: "!X (communication administratively prohibited)"
hmmhmmmhmhmmm
Oh, and then there's the fact that it wasn't changed at all.
PREVIOUS (AND CURRENT) ASSIGNMENT:
Furaffinity.net:
NS1: NS23.WORLDNIC.COM 205.178.190.12
NS2: NS24.WORLDNIC.COM 206.188.198.12
NS3: UNASSIGNED
NS4: UNASSIGNED
FACDN.NET:
NS1: NS95.WORLDNIC.COM 205.178.190.48
NS2: NS96.WORLDNIC.COM 206.188.198.48
NS3: UNASSIGNED
NS4: UNASSIGNED
70.33.186.192-70.33.186.223:
InfoRelay Online Systems, Inc. INFORELAY-NETBLOCK03 (NET-70-33-160-0-1) 70.33.160.0 - 70.33.191.255
Ferrox Art, LLC FERROXART-01 (NET-70-33-186-192-1) 70.33.186.192 - 70.33.186.223
NetRange: 70.33.186.192 - 70.33.186.223
CIDR: 70.33.186.192/27
OriginAS: AS33597
Comment: http://www.inforelay.com - static allocation
RegDate: 2010-05-06
Updated: 2010-05-06 <--- Oh hey look, it hasn't been changed in over 3 years!
-- dig www.furaffinity.net --
;; QUESTION SECTION:
;www.furaffinity.net. IN A
;; ANSWER SECTION:
www.furaffinity.net. 4946 IN A 70.33.186.196
;; AUTHORITY SECTION:
furaffinity.net. 163218 IN NS ns24.worldnic.com.
furaffinity.net. 163218 IN NS ns23.worldnic.com.
-- dig www.facdn.net --
;; QUESTION SECTION:
;www.facdn.net. IN A
;; ANSWER SECTION:
www.facdn.net. 7200 IN A 70.33.186.221
;; AUTHORITY SECTION:
facdn.net. 171210 IN NS ns95.worldnic.com.
facdn.net. 171210 IN NS ns96.worldnic.com.
-- dig -x 70.33.186.196 --
;; QUESTION SECTION:
;196.186.33.70.in-addr.arpa. IN PTR
;; ANSWER SECTION:
196.186.33.70.in-addr.arpa. 3600 IN PTR www.furaffinity.net.
;; AUTHORITY SECTION:
186.33.70.in-addr.arpa. 86368 IN NS NS4.SITELUTIONS.COM.
186.33.70.in-addr.arpa. 86368 IN NS NS1.SITELUTIONS.COM.
186.33.70.in-addr.arpa. 86368 IN NS NS3.SITELUTIONS.COM.
186.33.70.in-addr.arpa. 86368 IN NS NS2.SITELUTIONS.COM.
186.33.70.in-addr.arpa. 86368 IN NS NS5.SITELUTIONS.COM.
-- dig -x 70.33.186.221 --
;; AUTHORITY SECTION:
facdn.net. 171811 IN NS ns96.worldnic.com.
facdn.net. 171811 IN NS ns95.worldnic.com.
;; QUESTION SECTION:
;221.186.33.70.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
186.33.70.in-addr.arpa. 3600 IN SOA ns1.sitelutions.com. reverse-dns.sitelutions.com. 233 28000 7200 604800 1
Oh, but that's not even the problem box - which has been explained in great detail by yours truly previously. The problem box is 66.231.180.84 which is a broken firewall/load balancer.
Ferrox Art, LLC FERROXART-02 (NET-66-231-180-80-1) 66.231.180.80 - 66.231.180.95
InfoRelay Online Systems, Inc. INFORELAY-NETBLOCK01 (NET-66-231-176-0-1) 66.231.176.0 - 66.231.191.255
NetRange: 66.231.180.80 - 66.231.180.95
CIDR: 66.231.180.80/28
OriginAS: AS33597
NetName: FERROXART-02
RegDate: 2010-05-06
Updated: 2011-09-24 <-- Would you look at that.. it's not updated either!
;; QUESTION SECTION:
;84.180.231.66.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
180.231.66.in-addr.arpa. 3600 IN SOA ns1.sitelutions.com. info.inforelay.com. 33 28000 7200 604800 1
If you were actually committed to resolving these issues, you'd quit making things up and actually do some basic troubleshooting. The kind that even level 1 tech support knows how to do. Instead of claiming it's the magical somehow impossible to comprehend "DNS" and making a bunch of hand-wavy motions to blame users.
Tracing route to furaffinity.net [70.33.186.196]over a maximum of 30 hops:
....
7 101 ms 102 ms 102 ms cr2-tengig-0-15-0-0.Washington.savvis.net [204.70.196.102]
8 113 ms 103 ms 104 ms msr1-tengig-0-3-0-0.Washington.savvis.net [204.70.196.98]
9 119 ms 102 ms 102 ms er1-gig-3-0-1.dck.savvis.net [204.70.203.6]
10 101 ms 101 ms 101 ms dca1.inforelay.net [208.173.12.130]
11 301 ms 207 ms 215 ms cr2.iad3.inforelay.net [67.208.76.5]
12 101 ms 104 ms 101 ms cr2.iad2.inforelay.net [67.208.89.118]
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
http://www.internetpulse.net/Main.aspx?Metric=PL
C:\>pathping www.furaffinity.net
Tracing route to www.furaffinity.net [70.33.186.196]
over a maximum of 30 hops:
0 iMac-Windows [192.168.0.15]
1 192.168.0.1
2 207.225.112.254
3 * hlrn-agw1.inet.qwest.net [71.217.189.233]
4 lap-brdr-03.inet.qwest.net [67.14.22.78]
5 63-235-40-86.dia.static.qwest.net [63.235.40.86]
6 cr2-te-0-5-0-3.lay.savvis.net [206.28.97.249]
7 cr1-ten-0-13-1-0.dck.savvis.net [204.70.197.25]
8 msr1-tengig-0-0-0-0.Washington.savvis.net [204.70.196.94]
9 er1-gig-3-0-1.dck.savvis.net [204.70.203.6]
10 dca1.inforelay.net [208.173.12.130]
11 cr2.iad3.inforelay.net [67.208.76.5]
12 cr2.iad2.inforelay.net [67.208.89.118]
13 66.231.180.84
14 www.furaffinity.net [70.33.186.196]
Computing statistics for 350 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 iMac-Windows [192.168.0.15]
0/ 100 = 0% |
1 7ms 0/ 100 = 0% 0/ 100 = 0% 192.168.0.1
0/ 100 = 0% |
2 50ms 0/ 100 = 0% 0/ 100 = 0% 207.225.112.254
0/ 100 = 0% |
3 43ms 0/ 100 = 0% 0/ 100 = 0% hlrn-agw1.inet.qwest.net [71.217.189.233]
0/ 100 = 0% |
4 85ms 1/ 100 = 1% 1/ 100 = 1% lap-brdr-03.inet.qwest.net [67.14.22.78]
0/ 100 = 0% |
5 75ms 0/ 100 = 0% 0/ 100 = 0% 63-235-40-86.dia.static.qwest.net [63.235.40.86]
0/ 100 = 0% |
6 70ms 0/ 100 = 0% 0/ 100 = 0% cr2-te-0-5-0-3.lay.savvis.net [206.28.97.249]
0/ 100 = 0% |
7 115ms 0/ 100 = 0% 0/ 100 = 0% cr1-ten-0-13-1-0.dck.savvis.net [204.70.197.25]
0/ 100 = 0% |
8 116ms 0/ 100 = 0% 0/ 100 = 0% msr1-tengig-0-0-0-0.Washington.savvis.net [204.70.196.94]
0/ 100 = 0% |
9 114ms 0/ 100 = 0% 0/ 100 = 0% er1-gig-3-0-1.dck.savvis.net [204.70.203.6]
0/ 100 = 0% |
10 121ms 2/ 100 = 2% 2/ 100 = 2% dca1.inforelay.net [208.173.12.130]
0/ 100 = 0% |
11 116ms 1/ 100 = 1% 1/ 100 = 1% cr2.iad3.inforelay.net [67.208.76.5]
0/ 100 = 0% |
12 131ms 0/ 100 = 0% 0/ 100 = 0% cr2.iad2.inforelay.net [67.208.89.118]
83/ 100 = 83% |
13 117ms 83/ 100 = 83% 0/ 100 = 0% 66.231.180.84
0/ 100 = 0% |
14 114ms 83/ 100 = 83% 0/ 100 = 0% www.furaffinity.net [70.33.186.196]
Trace complete.
...
216.221.158.246 (inforelay-gw.p4.tinet.net)
66.231.176.10 (cr2.iad1.inforelay.net)
66.231.176.246 (cr1.iad2.inforelay.net)
66.231.180.84
70.33.186.196 (www.furaffinity.net)
However, I found that the protocol needs to be set to ICMP in the settings. If it's set to UDP, then it times out regardless of whether the website is "working" on my computer or not. You'll notice that for the people who are having problems, their packets are trying to go
67.208.89.118 (cr2.iad2.inforelay.net)
66.231.180.84
70.33.186.196 (www.furaffinity.net)
while for people who aren't having any problems, their packets are probably going like this
66.231.176.246 (cr1.iad2.inforelay.net)
66.231.180.84
70.33.186.196 (www.furaffinity.net)
Hope this helps
When the site doesn't respond, tracert looks like this:
13 148 ms 147 ms 147 ms dca1.inforelay.net [208.173.12.130]
14 147 ms 147 ms 145 ms cr2.iad3.inforelay.net [67.208.76.5]
15 147 ms 145 ms 147 ms cr2.iad2.inforelay.net [67.208.89.118]
16 * * * Request timed out.
When it's working, it looks like this:
13 148 ms 147 ms 147 ms dca1.inforelay.net [208.173.12.130]
14 147 ms 147 ms 147 ms cr2.iad3.inforelay.net [67.208.76.5]
15 146 ms 147 ms 147 ms cr2.iad2.inforelay.net [67.208.89.118]
16 146 ms 147 ms 147 ms 66.231.180.84
17 146 ms 147 ms 147 ms www.furaffinity.net [70.33.186.196]
i havent been on FA too much but ive been able to browse and stuff absolutely fine, havent submitted anything so im not sure about that.
if it means anything, i live in the UK?? i know most people live in the US so idk if that provides any kind of information
i hope it gets fixed soon because it sounds really bad ooh gosh
It isn't, hasn't been, and will not be DNS.
Your issue started after your upstream provider dicked about with that damned switch at the beginning of the month.
Tell your upstream provider to get off their sodding arses and fix, replace, or properly configure the equipment they putzed with earlier this month.
I'm not angry. I've had reliable access to art, but not here.
Other than that, its working fine :) Good luck fixing it!
Still keeps timing out for me as of this morning.
Works fine one minute, then several minutes of time outs, then works fine again. . .
I pray this issue be diagnosed and repaired soon.
}:>
Ferrox @ 66.231.180.84 doesn't accept ICMP (ping) requests from the internet. Is a firewall possibly incorrectly blocking some traffic or protocols from Inforelay's network or part of Inforelay's network that is needed to correctly calculate routes?
********************
As I pointed out above, the problem is with the connection between cr2.iad2.inforelay.net and 66.231.180.84 because the connection between cr1.iad2.inforelay.net and 66.231.180.84 is working just fine. Also, the connection from cr2.iad2.inforelay.net to cr1.iad2.inforelay.net is also working just fine. So if there were some way I could tell my packets to make one additional hop, I would be able to ping furaffinity just fine.
This throwing this out there, does Inforelay perform some sort of bandwidth calculation every 5 minutes for billing or potential throttling? What takes 5 minutes? OSPF convergence and routing updates? Cisco Enhanced Interior Gateway Routing Protocol restart time? I don't know but something seems to happen every 5 minutes.
please keep trying... -.-;;
Should I re-note my tracert?
Still having the same problems
We are on Brighthouse Networks (road runner) and we are having massive issues accessing FA.
At work, I use my Clear Spot and I too have issues connecting.
Just food for thought, hopefully it gets resolved. Honestly, I would ask the host that initially screwed up this for a credit due to the massive amounts of complaints and downtime. But thats just me.
continued to have the issues yesterday night [22june] while in a different state
return home today, still connection issues
primarily firefox for browser but also tried chrome and internet explorer
internet provider is comcast
also having the same issue with the browsers on my android phone and tablet through verizon
It's been 4 days, and the issue still is not resolved.
It is still works-for-a-few-minutes, no-response-and-timeouts-for-many.
And if this is on the FA server side shame on you FA admins for trying to pass on the blame.
With that said I love FA its a shame, and highly aggravating not being able to use one of my favorite sites.
6 116 ms 108 ms 158 ms 65.sub-69-83-32.myvzw.com [69.83.32.65]
7 55 ms 33 ms 42 ms port-channel1201.car2.Nashville1.Level3.net [4.59.200.37]
8 * * * * Request timed out
12 * * * * Request timed out
13 59 ms 59 ms 57 ms ae-32-80.car2.Washington1.Level3.net [4.69.149.132]
14 56 ms 58 ms 64 ms CWIE-LLC.car2.Washington1.Level3.net [4.59.156.58]
15 58 ms 63 ms 59 ms cr2.iad3.inforelay.net [70.33.180.254]
16 70 ms 65 ms 65 ms cr2.iad2.inforelay.net [67.208.89.118]
17 * * * * Request timed out
18 67 ms 61 ms 60 ms www.furaffinity.net [70.33.186.196]
Its somewhere in the inforelay routing
Tracing route to www.furaffinity.net [70.33.186.196]
...
16 286 ms 286 ms 286 ms ae-82-82.csw3.Washington1.Level3.net [4.69.134.154]
17 403 ms 363 ms 440 ms ae-32-80.car2.Washington1.Level3.net [4.69.149.132]
18 288 ms 289 ms 287 ms CWIE-LLC.car2.Washington1.Level3.net [4.59.156.58]
19 282 ms 284 ms 283 ms cr2.iad3.inforelay.net [70.33.180.254]
20 282 ms 374 ms 283 ms cr2.iad2.inforelay.net [67.208.89.118]
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
You'll notice that for the people who are having problems, their packets are trying to go
67.208.89.118 (cr2.iad2.inforelay.net)
66.231.180.84
70.33.186.196 (www.furaffinity.net)
while for people who aren't having any problems, their packets are probably going like this
66.231.176.246 (cr1.iad2.inforelay.net)
66.231.180.84
70.33.186.196 (www.furaffinity.net)
I'm still having problems by the way.
Please get this fixed.