Ok, so, give this a go. Bring up a command prompt and run it as an administrator. So, you would have to right click on the command prompt icon and select "Run as Administrator". At the command prompt, type in:
pathping www.citrix.com >c:\pingtest.txt
That will create a text file on C drive titled pingtest.txt. You can then copy the contents of that file and paste it into this thread. The pathping will trace the route down to Citrix and show where the losses are taking place along the path. This takes 200 seconds to run, during which time, the command prompt won't show anything. When its done, you will see a clean command prompt again.
The other thing you can do to trace the path is to run a tracert command. In this case, from a command prompt, you would type:
You can also run the trace to any other company or IP address. What you should see is a clean path to the end without any time outs. The problem now, is that with the routing table issues being sorted out, all you can to is look at the path and know whether or not to expect any issues in your day to day internet usage.
Here are the results of a tracert for www.rogers.com
Tracing route to e6313.g.akamaiedge.net [18.104.22.168]
over a maximum of 30 hops:
1 2 ms 1 ms <1 ms INTEL_CE_LINUX [10.0.0.1]
2 19 ms 19 ms 22 ms INTEL_CE_LINUX [22.214.171.124]
3 17 ms 17 ms 20 ms INTEL_CE_LINUX [126.96.36.199]
4 13 ms 15 ms 20 ms INTEL_CE_LINUX [188.8.131.52]
5 29 ms 29 ms 31 ms so-5-0-3.gw02.bloor.phub.net.cable.rogers.com [184.108.40.206]
6 27 ms 19 ms 26 ms INTEL_CE_LINUX [220.127.116.11]
7 29 ms 26 ms 29 ms a23-195-205-189.deploy.static.akamaitechnologies.com [18.104.22.168]
Computing statistics for 100 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0/ 100 = 0% |
1 6ms 0/ 100 = 0% 0/ 100 = 0% INTEL_CE_LINUX [192.168.0.1]
0/ 100 = 0% |
2 --- 100/ 100 =100% 100/ 100 =100% INTEL_CE_LINUX [22.214.171.124]
0/ 100 = 0% |
3 21ms 0/ 100 = 0% 0/ 100 = 0% INTEL_CE_LINUX [126.96.36.199]
100/ 100 =100% |
4 --- 100/ 100 =100% 0/ 100 = 0% INTEL_CE_LINUX [188.8.131.52]
That is interesting. It looks like the pathping is timing out and not completing. If you run a tracert command instead of a pathping, you will probably see a longer path and it should complete. The one thing to remember is that these commands are probably placed well down in the que for processing at the various interconnect points, so they might just end up timing out prior to completion at that point. So, that does not necessarily mean there is an issue at a given point. There are issues at some addresses which are known and which are currently presenting problems, but if you don't game, that shouldn't be a huge problem.
My guess at this time is that you should be in reasonable shape for tomorrow. Fwiw, I usually restart my CGN3 on a daily basis, even if it has been running overnight, which I don't always do. Its just a routine, start the computer and restart the CGN3, and I usually never experience any issues with it. So, you can do that through the Administration ...Device Reset page. All you have to do is select reboot. Or to reboot it manually, hold down the back reset button for less than 5 seconds. If you had the CGN3 connected with a power switch, you could just turn it off and back on again . To do the factory reset, hold it for more than 5 seconds. If you start having issues, try a reboot and see if that clears it up.
Edit: just checked the manual about the rear reset button:
Press the button and hold it for less than five seconds to reboot the CGN3. The CGN3 restarts, using your existing settings.
Press the button and hold it for more than five seconds to delete all user-configured settings and restart the CGN3 using its factory default settings.
All that is left is to reset your wifi setting: Recommendation: Use WPA2 AES with SSIDs and Passphrases which are at least 20 to 30 characters long and random, including symbols, characters and numbers. The SSID limit I believe is 32 characters and the passphrase is 63 or 64 characters, depending on what you use.
There is a way to copy from a command line prompt window:
On top left hand corner of the command prompt window, you should see a C:\. Right click on this symbol or anywhere on the top bar, and you should see a drop down list. Just below "Close", choose Edit and a second list should show up. Choose Select All (which will grab everything in the window), then on the same list, Choose Copy. You can then do a Paste in any other appllication like you would any other copy function. This should give you all content that was inside the Prompt Window. Good luck.
Hi, what a day. I was very good until 9:30am and everything just went down hill. I ended up going to the office to work. I followed the recommendations which worked for just more than an hour. I did tracert again and thanks for the tip here is the result. Please tell me I can still do something about this other than move.
Tracing route to www.gslb.citrix.com [184.108.40.206]
over a maximum of 30 hops:
1 9 ms 9 ms 64 ms INTEL_CE_LINUX [..0.1]
2 21 ms 19 ms 18 ms INTEL_CE_LINUX [220.127.116.11]
3 26 ms 30 ms 30 ms INTEL_CE_LINUX [18.104.22.168]
4 34 ms 20 ms 18 ms INTEL_CE_LINUX [22.214.171.124]
5 * 36 ms 29 ms INTEL_CE_LINUX [126.96.36.199]
6 22 ms 48 ms 28 ms gw-he.torontointernetxchange.net [188.8.131.52]
7 66 ms 55 ms 38 ms 100ge13-1.core1.chi1.he.net [184.108.40.206]
8 58 ms * * 10ge16-4.core1.dal1.he.net [220.127.116.11]
9 * * * Request timed out.
10 * 84 ms * g1-9.br2.dfw2.terremark.net [18.104.22.168]
11 78 ms 91 ms 92 ms g0-5-0-2.br2.dfw3.terremark.net [22.214.171.124]
12 135 ms 86 ms 84 ms t0-0-0-7.br2.mia.terremark.net [126.96.36.199]
13 * * 90 ms t9-1.gw1.mia.terremark.net [188.8.131.52]
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.
Don't have any ideas at this point, but can you describe what happens when, as you say, everything just went downhill? Do you start out with a good connection to citrix which then proceeds to degrade throughout the day? Do you run a constant connection or connect / disconnect / reconnect throughout the day? It would probably help if you were able to determine what the end IP address actually is, versus using www.citrix.com as a target for a trace. That is something you would have to determine from your IP support staff. It might just be that from work, there are leased, dedicated communication lines used to facilitate the type of operations and communications that you run during day to day work. It would be very difficult I think to compete with that using a home connection. Fwiw.....
We'll start off, that the last X many hops, are blank. That isnt necessarily out of place, and i wouldnt worry about that part.
Usually in those cases.. the ROUTE knows, it needs to go across x many more hops to get to point B... but at some point, its hitting a firewall. Its being allowed through... BUT, those points behind the firewall, etc, do not respond to pings, etc.
Hop 5, has a bit of a hickup there.. but not TOO Bad..
That it got the 2nd two responses and its sub 30..
This is the last node on the rogers before jumping off to #6, so that is where some of it might come from.
The bigger issues come from 8/9/10.
These are nodes down in the US.. looks like (at least by the registration) california and florida.
So the data, is taking QUITE the path to get to where it needs to go.
It appears, that these nodes down there, are the ones potentially having issues.
What can be done?
Thats the tough part. Directly from Rogers? Not much... they do not own those nodes. They cant fix them if its an issue.
Those nodes could be suffereing what ALOT of them are going through now with the full memory routing issues...
The only POSSIBLE thing MAYBE rogers could do, it re-routing.. IF they have peering deals with someone else, but could be an even longer route then, etc.
When you are connecting citrix... your connecting TO your office? (which is located where?)
If you are connecting via an address like you posted.. sounds like your connecting to a COULD bases citrix, then maybe it feeds back to your offices connection. The data seems like its going FARTHER than maybe needed? (vs direct connect to your office)