|
Las Vegas Peeps on COX Internet, can you pull up mojohost.com ?
I'm pulling out hair at this point, we can't get to our servers on http://Mojohost.com and there's absolutely nothing wrong with the trace route we pull from our boxes. We've had people try from other parts of the country, no problem getting to mojo host or our sites.
This is from two separate offices here in Vegas. No time out, nothing, it just keeps trying to reach the server, like it's going to a black hole. Been on the phone with COX, they say it's not them, and if I can reach the internet, their job is done. I tried to get escalated to level 2, and the fuckers sent me to a busy signal, so back on again with them. Can any Vegas Peeps on Cox try to get to Mojohost.com and see if it comes up for you? |
It loads fine, from Vegas on Cox
|
yes, just fine.
|
Try emailing Brad. I had a problem where my webair and mojo servers couldn't see each other for the life of me. Turned out it was a problem with Hurricane Electric routing. Brad and Corey are great at trying to diagnose these odd problems.
WG |
I can't reach it either
|
Quote:
COX is unhelpful to say the least. |
Quote:
Quote:
Quote:
|
Anthony- Have you tried changing your computer's dns servers away from cox?
Simple to do and sometimes thats the issue. I couldn't reach my bank and my ISP kept telling me that it was my computer until I showed them from a comp in their office. opendns.com is who I use. |
Its not loading here for me... just says waiting and then it times out.
|
i know Cox users in Kansas can't get to Mojo Host
|
It is a Cox issue, and Not all Cox ISP users.
I have been on the phone with Mojo, they are doing everything to get this worked out. I want to thank Mojo for staying with this issue and helping me out, way after hours! Toll Free: 888-345-MOJO |
Oh and COX can go jump in a river! If restarting your Modem doesn'tfix it, they are clueless
|
Cox AZ doesnt load,well hasnt loaded yet,been over a minute
|
Quote:
|
no wonder i cant connect to submitpasses.com all day they host at mojohost also =(
|
cant get mojohost to load either although the trace does look clean
|
No offense to Mojo, but it would seem it might be better for you to have a host with more than one upstream directly peered?
http://lg.onvoy.net/cgi-bin/bgplg?cm...208.122.217.60 BGP routing table entry for 208.122.192.0/19 7821 3356 7922 27589 Nexthop 172.30.0.54 (via 137.192.48.105) from PLMOCSR2 (172.30.0.51) Origin IGP, metric 0, localpref 80, internal, valid, best Last update: 06:39:05 ago Community: 5006:22 BGP routing table entry for 208.122.192.0/19 7821 3356 7922 27589 Nexthop 172.30.0.54 (via 137.192.48.105) from O511CSR2 (172.30.0.52) Origin IGP, metric 0, localpref 80, internal, valid Last update: 06:39:05 ago Community: 5006:22 |
working for me now
|
This isn't a public looking glass that you used, you are mis-informed. That link only showing the best path out at onvoy.net which happens to be Comcast.
https://supernoc.rogerstelecom.net/ops - Choose USA Route views from the drop down menu - Where it says enter your Query "208.122.192.0" - Select Run your Query Here is the output: Query: show ip bgp 208.122.192.0 BGP routing table entry for 208.122.192.0/19, version 257847 Paths: (34 available, best #33, table Default-IP-Routing-Table) Not advertised to any peer 3333 1299 27589 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin EGP, localpref 100, valid, external 701 1299 27589 157.130.10.233 from 157.130.10.233 (137.39.3.60) Origin EGP, localpref 100, valid, external 2914 1299 27589 129.250.0.11 from 129.250.0.11 (129.250.0.51) Origin EGP, metric 10, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:1299 2914 6453 27589 129.250.0.171 from 129.250.0.171 (129.250.0.79) Origin EGP, metric 5, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:6453 3549 7922 7922 7922 27589 208.51.134.254 from 208.51.134.254 (208.178.61.33) Origin EGP, metric 2500, localpref 100, valid, external 3267 6939 27589 27589 27589 194.85.40.15 from 194.85.40.15 (193.232.80.7) Origin IGP, localpref 100, valid, external 6079 6939 27589 27589 27589 207.172.6.1 from 207.172.6.1 (207.172.6.1) Origin IGP, metric 0, localpref 100, valid, external 6079 6939 27589 27589 27589 207.172.6.20 from 207.172.6.20 (207.172.6.20) Origin IGP, metric 0, localpref 100, valid, external 3277 3267 6939 27589 27589 27589 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65100 3277:65320 3277:65326 812 7922 27589 64.71.255.61 from 64.71.255.61 (64.71.255.61) Origin IGP, localpref 100, valid, external 2905 702 1299 27589 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin EGP, metric 0, localpref 100, valid, external 3356 7922 27589 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2012 65000:174 65000:209 65000:1239 65000:1280 65000:1299 65000:1668 65000:2828 65000:3257 65000:3320 65000:3549 65000:3561 65000:4637 65000:6453 65000:6762 65000:7018 65000:7132 65002:2914 65002:6461 65002:8220 4826 6939 27589 27589 27589 114.31.199.1 from 114.31.199.1 (114.31.199.1) Origin IGP, localpref 100, valid, external 852 1299 27589 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin EGP, metric 0, localpref 100, valid, external Community: 852:180 852 7922 27589 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin EGP, metric 0, localpref 100, valid, external Community: 852:180 2828 6453 27589 65.106.7.139 from 65.106.7.139 (66.239.189.139) Origin EGP, metric 3, localpref 100, valid, external 1668 6453 27589 66.185.128.48 from 66.185.128.48 (66.185.128.50) Origin EGP, metric 511, localpref 100, valid, external 286 1299 27589 134.222.87.1 from 134.222.87.1 (134.222.86.1) Origin EGP, localpref 100, valid, external Community: 286:80 286:800 286:3031 286:4001 2497 6453 27589 202.232.0.2 from 202.232.0.2 (202.232.0.2) Origin EGP, localpref 100, valid, external 5459 1299 27589 195.66.232.239 from 195.66.232.239 (195.66.232.239) Origin EGP, localpref 100, valid, external Community: 5459:1 5459:60 6453 27589 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin EGP, localpref 100, valid, external 3257 1299 27589 89.149.178.10 from 89.149.178.10 (213.200.87.91) Origin EGP, metric 10, localpref 100, valid, external Community: 3257:8100 3257:30052 3257:50001 3257:54900 3257:54901 6539 577 7922 27589 66.59.190.221 from 66.59.190.221 (66.59.190.221) Origin EGP, localpref 100, valid, external 6453 27589 207.45.223.244 from 207.45.223.244 (66.110.0.124) Origin EGP, localpref 100, valid, external 1221 4637 4637 4637 4637 6453 27589 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin EGP, localpref 100, valid, external 3561 7922 27589 206.24.210.102 from 206.24.210.102 (206.24.210.102) Origin EGP, localpref 100, valid, external 3303 1299 27589 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin EGP, localpref 100, valid, external Community: 3303:1004 3303:1006 3582 4600 11537 6939 27589 27589 27589 128.223.253.8 from 128.223.253.8 (128.223.253.8) Origin IGP, localpref 100, valid, external Community: 3582:567 4600:199 16150 6939 27589 27589 27589 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65320 16150:65334 16150:65351 7500 2497 6453 27589 202.249.2.86 from 202.249.2.86 (203.178.133.115) Origin EGP, localpref 100, valid, external 7018 1299 27589 12.0.1.63 from 12.0.1.63 (12.0.1.63) Origin EGP, localpref 100, valid, external Community: 7018:5000 7660 2516 6762 27589 27589 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin EGP, localpref 100, valid, external Community: 2516:1030 8075 27589 207.46.32.34 from 207.46.32.34 (207.46.32.34) Origin IGP, localpref 100, valid, external, best 6939 27589 27589 27589 216.218.252.164 from 216.218.252.164 (216.218.252.164) Origin IGP, localpref 100, valid, external This output shows you indeed that there are in fact many paths present between the combination of directly connected transit providers and peers that we have. Brad |
As far as the Cox problem, they are not a directly connected network. The problems that the users have been happening have been within Cox's network, outside of both ours and every directly connected transit provider that we connect to. We are doing everything possible. If anyone is still having a problem please email me directly with name, phone number, trace route into MojoHost and your actual IP address. I am also on icq but this information to email is most helpful.
Frustrating as this is, the problem is thankfully limited in scope to a subset of Cox users. Brad |
We have various reports from users who were previously having a problem connecting that they are able to reach us successfully. Please call, email or ICQ me if you are still having an issue.
Brad |
We are back up on our end and can touch our servers.
I want to thank Mojohost for being the most awesome host ever. |
Just to spread a little more accurate technical information on this issue:
The issue that was reported and still may be impacting select Cox Communications broadband users (reportedly mostly in Nevada and Kansas) apparently seems to be the result of some ICMP filtering that Cox has implemented within their network. Specifically, ICMP Type 3, Code 4 (datagram too big) appears to be getting dropped at points within their network affecting apparently a few fixed service areas. This block may have been put in to place by Cox for some security purpose, however what it is doing in reality is breaking a process known as Path MTU Discovery (PMTUd), which is used to calculate the highest supported maximum transmission unit (packet size) between two given end hosts, such as a user on their home computer and the server they are accessing across the Internet. With PMTUd not working properly for some clients, web servers at Mojohost may believe that an affected client can support a larger MTU (for example 1500, the standard Ethernet MTU) than they may be able to in reality, such as if they can only support an MTU of 1472 because of a PPPoE connection or VPN or something similar which would add overhead to a packet thus effectively lowering their MTU, etc. Diagnosing this issue is fairly straightforward. Users can complete normal traceroutes and pings, since they all (by default) use very small packets to function -- far below the MTU. Users may even be able to open an FTP or SSH session with their server. However, if any protocol they're using attempts to send large packets which approach or are at the MTU, and that MTU was miscalculated between the server and client due to a PMTUd failure, large packets would be dropped before reaching the client, causing pages not to load, transfers to freeze up, etc. We are (and have been) attempting to reach a *competent* Level-2/3 NOC technician at COX via one of our clients who is experiencing this issue, and is a direct COX customer. Unfortunately, we have no direct relationship with COX Communications ourselves, and they won't talk to us directly if we call their published NOC support numbers. There is a temporary *work-around* that clients impacted by this problem may use to allow access to a server while this problem continues, and that would be to manually lower their MTU value for their network connection. In most cases, setting an MTU value of 1460 or 1400 on a workstation that cannot access one of our servers should permit access until the underlying problem has been corrected by Cox. There may be a *slight* degradation in performance by implementing this suggestion that would normally only be seen on large long-lived file transfers due to the maximum packet size decreasing by 40 or 100 bytes (depending on which value you used), so if you implement this work-around, we advise resetting your MTU to its previous value (probably 1500) once the Cox issue has been confirmed as resolved. Here is a link to change your network connection MTU on the Windows XP/2000/03/Vista platform: http://www.windowsreference.com/wind...03-2000-vista/ Some other information regarding this problem can be found at: http://www.netheaven.com/pmtu.html http://tools.ietf.org/html/rfc2923 http://support.microsoft.com/kb/159211/ As mentioned above, we have reports from users that the problem is resolved. If anyone is still having a problem, please contact me directly or call 888-345-MOJO and press 1. Sincerely, Brad Mitchell |
I am Located in Kansas, and I can now hit my servers. I believe the issue is still not 100% fixed here in Kansas, as the websites seem to lag.
The computer that is set to 1400, has no problems or speed issues. I want to thank Mojo Host for all the late Tech time, and helping me with the work around to hit my sites. Thanks, Aron |
I can reach it. But funny enough I'm having the same problem with my servers at a different host.
|
Quote:
Brad |
I can reach servers on mojohost now as well
thank goodness all is working again |
Quote:
|
"Dont split/suavemente/omdc hosting have better things to do, than point fingers at other hosts that are in fact lightyears ahead of themselves - both when it comes to product and support? - just asking?"
I don't know, why don't you ask them. I am not related to them. |
Thanks again to everyone who helped in this thread, and mucho love for Brad and Mojohost!
|
By the way Brad, Mistake admitted, I thought I had the right pulldown selected and jumped to a conclusion. You gave great support to your customers. Heck, the time it took to type all that above alone was great support.
|
Quote:
I don't recall you being a client of ours and you can ask our clients we treat them well no matter what the situation. Peace |
Quote:
But stop that "throwing false accusations out without proof or you will get banned" - you sound like barefootsies when you write shit like that. I have had several clients that hosted with split |
Quote:
Anyways, lets kill the drama sorry if I came off as rude. I just have a passion about my job and the company I work for and get angry when people attack the company without cause. Something I admit I have to work on. Hope someday we can do some kind of biz together. Peace |
This is getting stupid, I cannot touch mojo servers again. Gonna try the mtu workaround.
|
Mojohost.com isn't reachable from here..
Microsoft Windows [Version 6.0.6001] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\racert mojohost.com Tracing route to mojohost.com [64.59.69.66] over a maximum of 30 hops: 1 27 ms 13 ms * ip68-102-224-1.ks.ok.cox.net [68.102.224.1] 2 13 ms 20 ms * ip70-183-64-73.ks.ks.cox.net [70.183.64.73] 3 32 ms 34 ms 28 ms dalsbbrj01-ae0.r2.dl.cox.net [68.1.0.142] 4 32 ms 30 ms 32 ms pos-1-5-0-0-cr01.dallas.tx.ibone.comcast.net [68 .86.86.89] 5 51 ms 51 ms 57 ms pos-0-12-0-0-cr01.atlanta.ga.ibone.comcast.net [ 68.86.85.158] 6 66 ms 67 ms 66 ms pos-0-6-0-0-cr01.miami.fl.ibone.comcast.net [68. 86.86.65] 7 67 ms 74 ms 65 ms 75.149.228.186 8 71 ms 64 ms 66 ms sh04.mojohost.com [64.59.69.66] Trace complete. C:\User |
No problem from here
3 ge-1-2-0-40.1000M.hgnqu1.ip.tele.dk [83.88.3.138] 4 ge-1-0-0-1000M.virnqu2.ip.tele.dk [83.88.29.254] 5 xe-1-0-0.virnxu5.dk.ip.tdc.net [83.88.4.161] 6 xe-0-0-0.virnxu4.dk.ip.tdc.net [83.88.2.253] 7 pos0-1-3-0.alb2nqh2.dk.ip.tdc.net [83.88.2.250] 8 ge-5-1-0.alb2nxu7.dk.ip.tdc.net [83.88.31.158] 9 kbn-b1.telia.net [195.215.109.2] 10 kbn-bb1-pos1-0-0.telia.net [213.248.65.9] 11 nyk-bb1-link.telia.net [213.248.64.22] 12 ash-bb1-link.telia.net [213.248.83.20] 13 atl-bb1-link.telia.net [80.91.252.218] 14 mai-bb1-link.telia.net [80.91.251.29] 15 mojohost-ic-124233-mai-b1.c.telia.net [213.248.104.166] 16 sh04.mojohost.com [64.59.69.66] |
I may be the Cox/MojoHost client Brad referred to above (or I may be one of many). I had numerous calls in with Tier2 tech support at Cox on Thursday as this was going on, and relayed stuff back and forth between the Cox tech and a Mojo tech on ICQ. What it comes down to is...
Brad's exactly right. This is a Cox issue, whether they choose to admit it or not. I'm back to hammering Cox (that sounds really bad) on this issue today. I don't really care if I personally have the problem, I can always drop the MTU setting on my router. But if CUSTOMERS can't reach my server, that's where I draw the line and I'm not backing down on this. Kudos to MojoHost and their exemplary tech support staff. We'll see if Cox can clear this up, because it's getting very old very fast. (P.S. Here's a good line to use when something like this happens (multiple people report outage). When the first-line tech support person says "it could be your wireless router," respond with "are you suggesting all the other people who are having the exact same problem are parked outside my house, leeching my wireless? Because I'm looking out the window and I don't see anyone." You'll get something along the lines of "ummm, errr." :thumbsup Matt @ MojoHost said it best... "Minimum wage, minimum work.") |
This was an awesome thread until Joel started talking...
Fuck you, Joel!!! |
I am unable to reach mojohost again as well.
Cox is getting on my nerves! |
Quote:
Do this, though, read Brad's long post above and do the workaround suggested in the last paragraph. It DOES work. It won't help your CUSTOMERS who are Cox users and can't reach your server... but at least YOU will be able to get some work done, while retaining at least a modicum of sanity. |
Still unreachable in Kansas through Cox
I have a very good connection.. I always make them run a new drop and I use a DC tap.. Plus I use good heavy center conductor drop wire throughout my home. It's wired perfectly. The good side of the tap goes to my modem, the weaker side goes directly to a signal booster AT THE BOX and then out to the televisions. Also the part I don't have knowledge of at all, the pole to pole lines, that is all very very good in my area. |
Also unreachable via Cox in Scottsdale, AZ.
|
not reachable from AZ cox.
|
Guys & gals, please do this if you can't access MojoHost through Cox, it's simple and fun (instructions are for Windows users, Mac users... well, do whatever's the equivalent):
Part 1 1) Open up a DOS window (Start button, Run, cmd) 2) Type tracert mojohost.com and press Enter. Part 2 When it's complete, you'll have a list of IP addresses along the way. For each of the IPs that come up in the list (except the first one if you're using a wireless router), type ping -l 1500 xxx.xxx.xxx.xxx replacing the x's with the IP and press Enter. This shoots a 1500 MTU packet through to that IP. If it's successful, repeat with the next IP until you get to one that times out. Part 3 Once you've got one with a timeout, right-click somewhere in the window and pick Select All. Everything will be highlighted. Then right-click again and the highlight should disappear. You just copied everything to the clipboard. Paste it into a new email. Part 4 Call Cox Internet Tech Support and tell them you're in the middle of an issue that Tier2 support is working on. If they won't immediately transfer you, tell the frontline tech that PMTUd is being broken by one of Cox's routers along the tracert and you have ping information that Tier2 needs. Get to Tier2 however you can, the frontline guys are pretty clueless. When you get a Tier2 tech, tell them that you're experiencing the MTU packet loss problem that Cox has had the past few days. This will establish with the tech that there's a current problem, in case they aren't aware. Next, tell them that normal size 1500 MTU packets are being dropped when you try to access THE SERVER THAT YOUR BUSINESS WEBSITE IS ON. This will establish that you aren't just having problems playing Warcrack. Finally, tell them you did a traceroute to your host, then ping'ed a 1500 MTU packet to each hop's IP. You have the point at which the packet is being dropped, you'd like to email the results to them, and to what email should you send it. If enough people do this, from enough different cities/regions, maybe there'll be some definitive action taken on this. Goodnight and good luck. :thumbsup Note: This is bouncing around the upper limits of my tech knowledge in this area. If I'm incorrect on something or there's a better way, someone feel free to post a correction and call me a dipshit or whatever's on your mind at the moment. |
Fucking cox had to decrease my packet size to get to my servers. I would cancel if I actually had a fucking alternate service in my area.
|
Brings back memories of the first DSL trials and initial takeup in Australia around the start of the millenium... at that time many sites simply blocked all ICMP, which breaks MTU discovery. No problems on analog modems, but those pesky PPPoE customers suddenly found they couldn't load their favourite sites. If you think it's hard getting a single ISP to remove or modify a firewall rule, imagine trying to educate hundreds of sites on why blocking *all* ICMP is a bad idea..... hey dude, it works off the office LAN, it works on my modem at home, GGF
|
Yep, problem still exists. This is really getting old. Time for more phone action.
|
Anyone on COX experiencing this problem please email [email protected] with your IP address and also a trace to mojohost.com
Unbelievable. Thank you, Brad |
It's all reachable, for me, now..
|
| All times are GMT -7. The time now is 01:48 PM. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc123