I have tried everything to post under services in marketplace and every time I get the following error ================= Server did not respond in time when fetching http:// xxxx (offline or too slow?). Server did not respond in time when fetching http:// xxxx(offline or too slow?). ================= I checked and there is absolutely nothing wrong with our site. It is not offline nor is it too slow
What is the URL you are trying to post? Put it in a [code] BBCode block so it doesn't treat it as a URL like so: [code]http://example.com[/code]
How can we get this resolved? and is this the only way to get support? I signed up for premium membership to be able to post in market place and so far it's simply not working for us.
Looks like your upstream connectivity provider is having routing issues. It seems the IP address is reachable from some locations, but not all. For example if you run this test tool that checks connectivity from different locations around the world, about half the locations can't reach your site: http://tools.maxcdn.com/ping?d1=proactiveservermanagement.com&d2=google.com
Thanks. We have corrected the routing issue, however the issue persists. This is the only place this happens
Definitely seems better, but not completely fixed. I wonder if it might be a peering issue with your host or something... because if I do a trace route from one of our servers, it gets as far as this: 11 lag-core-a.dist-1-3.clay1.mci.us.as32097.net (192.187.107.5) 44.380 ms lag-core-b.dist-1-3.clay1.mci.us.as32097.net (208.110.88.5) 44.429 ms lag-core-a.dist-1-3.clay1.mci.us.as32097.net (192.187.107.5) 45.450 ms Code (markup): Which is in Kansas City... From the looks of it, your servers are also in Kansas City, so wherever the routing issue is, it looks like it's very close. A traceroute from a different machine also here in San Diego, but on a different ISP is able to get through to your servers. The next hop past the last one that is working on the route is "vm.layeredvps.com". So from our data center, we are able to get to Kansas City, but not to the vm.layeredvps.com IP address (which looks like it might be your direct upstream provider).
Still unable to correct this with the limited info we have. Our DC took a look, solusvm took a look and our admins took a look and cannot find the issue. It's odd because we don't see this issue anywhere else Can you provide the IP from the server that is blocking this?
Still seeing it the same as before... the network traffic gets as far as this: lag-core-a.dist-1-3.clay1.mci.us.as32097.net (192.187.107.5) 46.048 ms lag-core-b.dist-1-3.clay1.mci.us.as32097.net (208.110.88.5) 45.240 ms lag-core-a.dist-1-3.clay1.mci.us.as32097.net (192.187.107.5) 45.526 ms Code (markup):
Can you send me the results of a MTR report and/or can one of our admins contact you directly? Or will they need to signup here and update this thread
Can we get some input on this? We have spent hours on this and do not see any issue anywhere else. For our site to be blocked by one server is odd to say it's on our end and we can find no evidence of this. Please update us, or let me know how to cancel our 6 month premium membership and get a refund. If we cant post it is useless
Not sure what kind of input you want beyond what I already gave you in this post. From our servers, we can get connectivity pretty close to your physical servers (all the way to Kansas City, which I believe is the city your servers are in), but the router given in that post isn't routing any traffic beyond that. I never said it was an issue on your end, rather an issue with one of your upstream providers. Specifically, it appears to be a routing issue within the wholesaleinternet.net network (judging from their contact page, they are indeed in Kansas City). Traffic gets into their network, but not through. As you mentioned in a previous post, there *was* a routing issue that you were able to correct. What exactly what the issue there that was corrected? Are you absolutely certain it was 100% corrected? A traceroute once leaving our data center looks like so: traceroute to proactiveservermanagement.com (173.208.194.180), 30 hops max, 40 byte packets using UDP ...internal IPs clipped... 4 ge4-16-ext-150.castleaccess.com (69.43.169.100) 5.050 ms 4.865 ms 4.888 ms 5 any2ix.coresite.com (206.72.210.122) 104.649 ms 103.724 ms 103.171 ms 6 10ge14-1.core1.den1.he.net (72.52.92.37) 54.784 ms 54.063 ms 53.604 ms 7 10ge5-5.core1.mci3.he.net (184.105.222.22) 66.088 ms 65.030 ms 63.796 ms 8 10ge4-1.core1.mci2.he.net (184.105.213.37) 55.446 ms 54.451 ms 54.459 ms 9 wholesale-internet-inc.10gigabitethernet1-3.core1.mci2.he.net (216.66.78.90) 54.949 ms 54.080 ms 53.096 ms 10 lag-to-oak.edge-b.clay1.mci.us.as32097.net (69.30.209.138) 45.910 ms 45.876 ms lag-to-oak.edge-a.clay1.mci.us.as32097.net (69.30.209.163) 46.224 ms 11 lag-core-a.dist-1-3.clay1.mci.us.as32097.net (192.187.107.5) 44.327 ms lag-core-b.dist-1-3.clay1.mci.us.as32097.net (208.110.88.5) 44.428 ms lag-core-a.dist-1-3.clay1.mci.us.as32097.net (192.187.107.5) 56.579 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Code (markup):
The issue that was corrected was a firewall issue in the server and yes it was resolved and triple checked. The DC is requiring the IP of the server trying to reach our server
Our server IPs are private... but an upstream IP from the traceroute would work just as well. For example: 69.43.169.100
We have spent weeks and countless hours on this, not only reinstalling the os, and troubleshooting, but trying to get somewhere with the DC. They show absolutely nothing wrong with their network and refuse to do any more unless we can provide them a MTR report. Cant you do this and strip your private server IPs? If you are unable or unwilling to provide this, please let me know how to cancel the premium membership and get a refund. I'm sorry but I am not willing to deal with this any longer, just to be able to post in your market place forum. We have spent way too much time on this. Maybe you should consider removing some of your restrictions. This is the only place we have seen these kind of issues.... ever. I would say, if anything changes in the future, I would consider signing up again, but without being able to test it, that is unfortunately very unlikely.
Dunno if I'm allowed to comment in a support-thread, but I tried doing a traceroute to the IP provided here, and it goes fine - however, there's only two hops missing from the try DP did, and the first of the two is vm.layeredvps.com [173.208.214.106] - which suggests the problem lies on your end (that's the one that times out in the traceroute above) - which means that's the hop that refuses to connect - unless DP has some VERY weird firewall rules (of which it would make no sense to block external server access from within), the problem is on your end.
Never said it wasn't on our end. If you fully read the post I said the DC will not do anything further without a MTR report. They need this to troubleshoot it further. Simply telling the DC it is on their end does nothing. That being said we do not want to deal with this anymore. It has wastes way too mush of our time and we require a refund!
Sure, although an MTR report is basically just a traceroute that runs multiple times (the only reason I can think of that someone would require an mtr report vs. a traceroute report to be able to diagnose something would be if they were hoping it wouldn't be sent so they didn't have to mess with it ). . Here it is: 1 (0.0.0.0) Mon Jul 20 11:40:03 2015 Resolver: Received error response 2. (server failure)er of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. internal-ip 0.0% 33 1.7 1.7 0.8 3.3 0.6 2. internal-ip 0.0% 33 0.2 0.4 0.2 4.6 0.8 3. internal-ip 0.0% 33 0.5 18.8 0.4 252.9 56.7 4. ge4-16-ext-150.castleaccess.com 0.0% 33 5.3 21.8 4.9 207.2 47.9 5. any2ix.coresite.com 0.0% 33 52.0 31.5 4.0 121.3 27.6 6. 10ge14-1.core1.den1.he.net 0.0% 33 54.3 58.5 54.3 67.6 4.7 7. 10ge5-5.core1.mci3.he.net 0.0% 33 58.7 58.4 55.4 72.6 4.1 8. 10ge4-1.core1.mci2.he.net 0.0% 33 64.9 59.0 55.6 73.6 4.5 9. wholesale-internet-inc.10gigabitethernet1-3.core1.mci2.he.net 0.0% 33 57.8 48.8 45.7 62.5 4.5 10. lag-to-oak.edge-b.clay1.mci.us.as32097.net 0.0% 33 46.0 46.2 45.9 51.6 1.0 11. lag-core-a.dist-1-3.clay1.mci.us.as32097.net 0.0% 33 45.8 50.2 45.7 60.9 4.7 12. ??? Code (markup):
Sent you a PM a week ago and haven't heard a word. I still cant post no matter what we do and this is the last time I am requesting a refund before I take it up with our cc provider