01-10-2015 10:29:48 | | Project communication failed: attempting access to reference site
01-10-2015 10:29:49 | | Internet access OK - project servers may be temporarily down.
01-10-2015 10:30:16 | | Project communication failed: attempting access to reference site
01-10-2015 10:30:17 | | Internet access OK - project servers may be temporarily down.
01-10-2015 12:24:57 | | Project communication failed: attempting access to reference site
01-10-2015 12:25:19 | | BOINC can't access Internet - check network connection or proxy configuration.
01-10-2015 13:03:00 | | Project communication failed: attempting access to reference site
01-10-2015 13:03:12 | | BOINC can't access Internet - check network connection or proxy configuration.
01-10-2015 14:13:16 | | Project communication failed: attempting access to reference site
01-10-2015 14:13:17 | | Internet access OK - project servers may be temporarily down.
01-10-2015 16:56:25 | | Project communication failed: attempting access to reference site
01-10-2015 16:56:47 | | BOINC can't access Internet - check network connection or proxy configuration.
01-10-2015 17:06:35 | SETI@home | update requested by user
01-10-2015 17:06:37 | SETI@home | Sending scheduler request: Requested by user.
01-10-2015 17:06:37 | SETI@home | Not requesting tasks: don't need (CPU: not highest priority project; Miner ASIC: not highest priority project; AMD/ATI GPU: job cache full)
01-10-2015 17:06:58 | SETI@home | Scheduler request failed: Couldn't connect to server
01-10-2015 17:06:59 | | Project communication failed: attempting access to reference site
01-10-2015 17:07:00 | | Internet access OK - project servers may be temporarily down.
01-10-2015 17:07:32 | | Project communication failed: attempting access to reference site
01-10-2015 17:07:33 | | Internet access OK - project servers may be temporarily down.
01-10-2015 17:09:20 | | Project communication failed: attempting access to reference site
01-10-2015 17:09:21 | | Internet access OK - project servers may be temporarily down.
01-10-2015 17:11:33 | | Project communication failed: attempting access to reference site
01-10-2015 17:11:34 | | Internet access OK - project servers may be temporarily down.
01-10-2015 17:15:04 | | Project communication failed: attempting access to reference site
01-10-2015 17:15:05 | | Internet access OK - project servers may be temporarily down.
01-10-2015 17:21:01 | | Project communication failed: attempting access to reference site
01-10-2015 17:21:02 | | Internet access OK - project servers may be temporarily down.
01-10-2015 17:32:29 | | Project communication failed: attempting access to reference site
01-10-2015 17:32:30 | | Internet access OK - project servers may be temporarily down.
01-10-2015 18:03:23 | | Project communication failed: attempting access to reference site
01-10-2015 18:03:24 | | Internet access OK - project servers may be temporarily down.
01-10-2015 18:28:37 | | Project communication failed: attempting access to reference site
01-10-2015 18:28:38 | | Internet access OK - project servers may be temporarily down.
01-10-2015 18:43:35 | | Project communication failed: attempting access to reference site
01-10-2015 18:43:36 | | Internet access OK - project servers may be temporarily down.
01-10-2015 20:45:55 | | Project communication failed: attempting access to reference site
01-10-2015 20:45:57 | | Internet access OK - project servers may be temporarily down.
01-10-2015 21:45:17 | SETI@home | update requested by user
01-10-2015 21:45:22 | SETI@home | Sending scheduler request: Requested by user.
01-10-2015 21:45:22 | SETI@home | Not requesting tasks: don't need (CPU: not highest priority project; Miner ASIC: not highest priority project; AMD/ATI GPU: job cache full)
01-10-2015 21:45:44 | SETI@home | Scheduler request failed: Couldn't connect to server
01-10-2015 21:45:46 | | Project communication failed: attempting access to reference site
01-10-2015 21:45:48 | | Internet access OK - project servers may be temporarily down.
01-10-2015 21:46:14 | | Project communication failed: attempting access to reference site
01-10-2015 21:46:15 | | Internet access OK - project servers may be temporarily down.
01-10-2015 23:22:16 | | Project communication failed: attempting access to reference site
01-10-2015 23:22:18 | | Internet access OK - project servers may be temporarily down.
01-10-2015 23:22:43 | SETI@home | update requested by user
01-10-2015 23:22:47 | SETI@home | Sending scheduler request: Requested by user.
01-10-2015 23:22:47 | SETI@home | Not requesting tasks: don't need (CPU: job cache full; Miner ASIC: not highest priority project; AMD/ATI GPU: job cache full)
01-10-2015 23:23:09 | SETI@home | Scheduler request failed: Couldn't connect to server
01-10-2015 23:23:10 | | Project communication failed: attempting access to reference site
01-10-2015 23:23:11 | | Internet access OK - project servers may be temporarily down.
01-10-2015 23:23:37 | | Project communication failed: attempting access to reference site
01-10-2015 23:23:38 | | Internet access OK - project servers may be temporarily down.

---

Wow I got a trace route to complete

5 67 ms 62 ms 62 ms xe-0-1-1.mpr2.tor1.ca.above.net [208.184.108.57]

6 73 ms 68 ms 62 ms xe-4-3-0.cr1.ord2.us.zip.zayo.com [64.125.22.226
]
7 76 ms 76 ms 74 ms ae12.mpr1.den1.us.zip.zayo.com [64.125.20.250]
8 98 ms 75 ms 76 ms ae5.cr1.sjc2.us.zip.zayo.com [64.125.25.53]
9 92 ms 76 ms 76 ms ae6.mpr1.pao1.us.zip.zayo.com [64.125.31.46]
10 77 ms 78 ms 78 ms oak-agg4-paix-sv8--zayo.cenic.net [198.32.251.12
5]
11 78 ms 77 ms 78 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31]
12 78 ms 78 ms 78 ms t2-3.inr-201-sut.Berkeley.EDU [128.32.0.37]
13 78 ms 78 ms 94 ms et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101]

14 76 ms 78 ms 78 ms muarae1.ssl.berkeley.edu [208.68.240.110]

Trace complete.

---

Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others;

I think you can get through to all of them, but only muarae1 is configured to reveal its name in response to a tracert probe.

setiboinc.ssl.berkeley.edu is accessible, it is the Apache test page, so failing to report wus is after this server. I have been unable to report wus since about 1400 yesterday.

---

Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others;

I think you can get through to all of them, but only muarae1 is configured to reveal its name in response to a tracert probe.

The only one I can reach is synergy and it doesn't go through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99). Both 'download server 1 - georgem' and 'upload server - bruno' go through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) and can not be reached. See my previous posts.

Apparently you can also reach vader;

traceroute to vader.ssl.berkeley.edu (208.68.240.127), 64 hops max, 72 byte packets
 1  192.168.1.1 (192.168.1.1)  1.032 ms  0.721 ms  0.399 ms
 2  l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1)  8.188 ms  7.984 ms  7.737 ms
 3  g0-5-5-0.tampfl-lcr-21.verizon-gni.net (130.81.109.254)  12.182 ms  9.745 ms  9.727 ms
 4  * * *
 5  0.ae3.br1.mia19.alter.net (140.222.225.111)  20.152 ms  19.550 ms  19.952 ms
 6  * lag-10.ear2.miami2.level3.net (4.68.71.169)  20.136 ms  19.814 ms
 7  ae-31-51.ebr1.miami1.level3.net (4.69.138.91)  69.896 ms  72.222 ms  70.430 ms
 8  ae-2-2.ebr1.dallas1.level3.net (4.69.140.133)  69.643 ms  69.846 ms  69.622 ms
 9  ae-71-71.csw2.dallas1.level3.net (4.69.151.137)  72.434 ms  69.303 ms  72.357 ms
10  ae-73-73.ebr3.dallas1.level3.net (4.69.151.146)  70.467 ms  71.893 ms  72.896 ms
11  ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77)  69.459 ms  69.561 ms  69.688 ms
12  ae-92-92.csw4.losangeles1.level3.net (4.69.137.30)  72.406 ms  72.138 ms  69.649 ms
13  * * *
14  cenic.ear1.losangeles1.level3.net (4.35.156.66)  71.076 ms  69.449 ms  69.726 ms
15  dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1)  80.117 ms  78.655 ms  79.892 ms
16  dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144)  80.287 ms  79.240 ms  79.861 ms
17  ucb--oak-agg4-10g.cenic.net (137.164.50.31)  84.935 ms  79.250 ms  80.214 ms
18  t2-3.inr-201-sut.berkeley.edu (128.32.0.37)  81.834 ms  79.879 ms  79.857 ms
19  et3-48.inr-311-ewdc.berkeley.edu (128.32.0.101)  82.140 ms  81.562 ms  83.228 ms
20  et3-48.inr-311-ewdc.berkeley.edu (128.32.0.101)  1454.793 ms !H  2996.669 ms !H  3035.443 ms !H

It doesn't use e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) either.

setiboinc.ssl.berkeley.edu is accessible, it is the Apache test page, so failing to report wus is after this server. I have been unable to report wus since about 1400 yesterday.

Did you see my edit to message 1730835?

The full scheduler url is

http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi

and responds correctly. The Apache test page simply shows that this server hasn't been configured as a web server: it has a different role to perform.

Richard
I tried to trace setiboinc.ssl.berkeley.edu and got this:

Tracing route to setiboinc.ssl.berkeley.edu [208.68.240.126]
over a maximum of 30 hops:
11 75 ms 77 ms 75 ms calren-cenic.paix.net [198.32.176.33]
12 77 ms 78 ms 77 ms dc-oak-agg4--paix-px1-ge.cenic.net [137.164.47.19]
13 78 ms 78 ms 78 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31]
14 275 ms 78 ms 79 ms t2-3.inr-201-sut.Berkeley.EDU [128.32.0.37]
15 78 ms 78 ms 78 ms et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101]
16 et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101] reports: Destination host unreachable.

Trace complete.

I also tried to put the complete URL into the browser bar, and it just timed out.
Any more suggestions?
Thanks
Bruce

---

Bruce

Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others;

I think you can get through to all of them, but only muarae1 is configured to reveal its name in response to a tracert probe.

The only one I can reach is synergy and it doesn't go through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99). Both 'download server 1 - georgem' and 'upload server - bruno' go through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) and can not be reached. See my previous posts.

And my previous posts? So far as I can diagnose, the main problem is reaching setiboinc.ssl.berkeley.edu (that's synergy, the scheduling server) through et3-47.inr-311 or et3-48.inr-311 - that combination consistently comes back (from the routing chosen by my ISP) as "Destination host unreachable". That at least is explicit, unlike the rows of asterisks which you are interpreting as 'can't get through', and I'm interpreting as 'stealthed - no name revealed' (but active).

Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others;

I think you can get through to all of them, but only muarae1 is configured to reveal its name in response to a tracert probe.

The only one I can reach is synergy and it doesn't go through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99). Both 'download server 1 - georgem' and 'upload server - bruno' go through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) and can not be reached. See my previous posts.

And my previous posts? So far as I can diagnose, the main problem is reaching setiboinc.ssl.berkeley.edu (that's synergy, the scheduling server) through et3-47.inr-311 or et3-48.inr-311 - that combination consistently comes back (from the routing chosen by my ISP) as "Destination host unreachable". That at least is explicit, unlike the rows of asterisks which you are interpreting as 'can't get through', and I'm interpreting as 'stealthed - no name revealed' (but active).

Vader is a DL server, just as georgem. Apparently you can also reach vader;

traceroute to vader.ssl.berkeley.edu (208.68.240.127), 64 hops max, 72 byte packets
 1  192.168.1.1 (192.168.1.1)  1.032 ms  0.721 ms  0.399 ms
 2  l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1)  8.188 ms  7.984 ms  7.737 ms
 3  g0-5-5-0.tampfl-lcr-21.verizon-gni.net (130.81.109.254)  12.182 ms  9.745 ms  9.727 ms
 4  * * *
 5  0.ae3.br1.mia19.alter.net (140.222.225.111)  20.152 ms  19.550 ms  19.952 ms
 6  * lag-10.ear2.miami2.level3.net (4.68.71.169)  20.136 ms  19.814 ms
 7  ae-31-51.ebr1.miami1.level3.net (4.69.138.91)  69.896 ms  72.222 ms  70.430 ms
 8  ae-2-2.ebr1.dallas1.level3.net (4.69.140.133)  69.643 ms  69.846 ms  69.622 ms
 9  ae-71-71.csw2.dallas1.level3.net (4.69.151.137)  72.434 ms  69.303 ms  72.357 ms
10  ae-73-73.ebr3.dallas1.level3.net (4.69.151.146)  70.467 ms  71.893 ms  72.896 ms
11  ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77)  69.459 ms  69.561 ms  69.688 ms
12  ae-92-92.csw4.losangeles1.level3.net (4.69.137.30)  72.406 ms  72.138 ms  69.649 ms
13  * * *
14  cenic.ear1.losangeles1.level3.net (4.35.156.66)  71.076 ms  69.449 ms  69.726 ms
15  dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1)  80.117 ms  78.655 ms  79.892 ms
16  dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144)  80.287 ms  79.240 ms  79.861 ms
17  ucb--oak-agg4-10g.cenic.net (137.164.50.31)  84.935 ms  79.250 ms  80.214 ms
18  t2-3.inr-201-sut.berkeley.edu (128.32.0.37)  81.834 ms  79.879 ms  79.857 ms
19  et3-48.inr-311-ewdc.berkeley.edu (128.32.0.101)  82.140 ms  81.562 ms  83.228 ms
20  et3-48.inr-311-ewdc.berkeley.edu (128.32.0.101)  1454.793 ms !H  2996.669 ms !H  3035.443 ms !H

It doesn't use e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) either.

No problem with synergy.ssl.berkeley.edu or setiboinc.ssl.berkeley.edu;

traceroute to synergy.ssl.berkeley.edu (208.68.240.126), 64 hops max, 72 byte packets
 1  192.168.1.1 (192.168.1.1)  0.895 ms  0.560 ms  0.442 ms
 2  l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1)  8.562 ms  8.374 ms  5.681 ms
 3  g0-5-5-0.tampfl-lcr-22.verizon-gni.net (130.81.110.228)  10.467 ms  12.573 ms  10.213 ms
 4  * * *
 5  0.ae4.br1.mia19.alter.net (140.222.225.113)  16.848 ms  16.619 ms  18.498 ms
 6  * * *
 7  ae-31-51.ebr1.miami1.level3.net (4.69.138.91)  70.927 ms  68.923 ms  70.445 ms
 8  ae-2-2.ebr1.dallas1.level3.net (4.69.140.133)  67.910 ms  68.876 ms  70.407 ms
 9  ae-71-71.csw2.dallas1.level3.net (4.69.151.137)  66.598 ms  69.800 ms  67.436 ms
10  ae-73-73.ebr3.dallas1.level3.net (4.69.151.146)  69.637 ms  69.828 ms  69.641 ms
11  ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77)  70.175 ms  69.365 ms  70.331 ms
12  ae-82-82.csw3.losangeles1.level3.net (4.69.137.26)  69.734 ms  69.815 ms  69.736 ms
13  * * ae-3-80.ear1.losangeles1.level3.net (4.69.144.146)  69.610 ms
14  cenic.ear1.losangeles1.level3.net (4.35.156.66)  72.047 ms  69.532 ms  70.405 ms
15  dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1)  77.198 ms  76.836 ms  77.674 ms
16  dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144)  79.919 ms  79.469 ms  79.893 ms
17  ucb--oak-agg4-10g.cenic.net (137.164.50.31)  80.174 ms  79.456 ms  79.903 ms
18  t2-3.inr-202-reccev.berkeley.edu (128.32.0.39)  79.889 ms  79.415 ms  80.158 ms
19  et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103)  79.853 ms  79.539 ms  79.896 ms
20  * et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103)  834.904 ms !H *
21  et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103)  1076.594 ms !H *  1045.139 ms !H

traceroute to setiboinc.ssl.berkeley.edu (208.68.240.126), 64 hops max, 72 byte packets
 1  192.168.1.1 (192.168.1.1)  1.566 ms  0.899 ms  2.027 ms
 2  l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1)  8.510 ms  6.175 ms  7.507 ms
 3  g0-5-5-0.tampfl-lcr-22.verizon-gni.net (130.81.110.228)  10.440 ms  11.989 ms  12.743 ms
 4  * * *
 5  0.ae4.br1.mia19.alter.net (140.222.225.113)  17.883 ms  41.065 ms  24.951 ms
 6  lag-10.ear2.miami2.level3.net (4.68.71.169)  17.979 ms  16.576 ms  18.695 ms
 7  ae-31-51.ebr1.miami1.level3.net (4.69.138.91)  69.439 ms  69.946 ms  69.459 ms
 8  ae-2-2.ebr1.dallas1.level3.net (4.69.140.133)  70.410 ms  71.108 ms  69.756 ms
 9  ae-71-71.csw2.dallas1.level3.net (4.69.151.137)  68.024 ms  69.923 ms  69.677 ms
10  ae-73-73.ebr3.dallas1.level3.net (4.69.151.146)  70.468 ms  70.837 ms  69.926 ms
11  ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77)  67.937 ms  69.898 ms  66.477 ms
12  ae-82-82.csw3.losangeles1.level3.net (4.69.137.26)  70.157 ms  72.756 ms  69.423 ms
13  * * *
14  cenic.ear1.losangeles1.level3.net (4.35.156.66)  71.112 ms  70.298 ms  69.129 ms
15  dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1)  77.938 ms  76.510 ms  77.736 ms
16  dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144)  79.896 ms  79.643 ms  79.781 ms
17  ucb--oak-agg4-10g.cenic.net (137.164.50.31)  79.917 ms  79.488 ms  79.916 ms
18  t2-3.inr-202-reccev.berkeley.edu (128.32.0.39)  80.193 ms  79.144 ms  79.938 ms
19  et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103)  79.926 ms  79.383 ms  80.184 ms
20  et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103)  1479.304 ms !H *  1102.453 ms !H

I also tried to put the complete URL into the browser bar, and it just timed out.
Any more suggestions?
Thanks
Bruce

That confirms the same blockage that I've just tried to describe to TBar. I'm getting through roughly 50% of my attempts - it seems to vary from ISP to ISP. I must have hit lucky when I tried that full cgi address, and pasted the reply. The only suggestion from that point forward is abuse of the update button.

Or drowning your sorrows in a pint of beer, which it where I'm heading now. Time out.

Well, here's the difference when I can reach the BOINC forums, as I now can. It's as if someone got off the line. 14:51 in San Francisco, someone went home early to prepare a secret for my birthday in 8 minutes?

Tracing route to boinc.berkeley.edu [208.68.240.115]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms 10 ms 6 ms 10.254.138.1
3 7 ms 7 ms 7 ms tb-rc0001-cr101-xe-0-3-4-0.core.as9143.net [213.51.186.180]
4 10 ms 10 ms 9 ms asd-tr0042-cr101-ae5-0.core.as9143.net [213.51.158.18]
5 12 ms 10 ms 9 ms lag-19.ear2.Amsterdam1.Level3.net [212.72.42.245]
6 * * 154 ms ae-2-70.ear1.SanJose1.Level3.net [4.69.152.87]
7 156 ms 155 ms 154 ms ae-2-70.ear1.SanJose1.Level3.net [4.69.152.87]
8 168 ms 169 ms 169 ms CENIC.ear1.SanJose1.Level3.net [4.15.122.46]
9 170 ms 171 ms 169 ms dc-oak-agg4--svl-agg4-100ge.cenic.net [137.164.46.144]
10 171 ms 172 ms 171 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31]
11 170 ms 171 ms 171 ms t2-3.inr-201-sut.Berkeley.EDU [128.32.0.37]
12 170 ms 171 ms 171 ms et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101]
13 170 ms 172 ms 171 ms isaac.ssl.berkeley.edu [208.68.240.115]

Trace complete.

---

I also tried to put the complete URL into the browser bar, and it just timed out.
Any more suggestions?
Thanks
Bruce

That confirms the same blockage that I've just tried to describe to TBar. I'm getting through roughly 50% of my attempts - it seems to vary from ISP to ISP. I must have hit lucky when I tried that full cgi address, and pasted the reply. The only suggestion from that point forward is abuse of the update button.

Or drowning your sorrows in a pint of beer, which it where I'm heading now. Time out.

LOL. Since I'm a tea totaller, I will have to settle for Earl Grey for my drowning.

Bruce

---

Bruce

And BOINC forums are again out of my reach. Oh well.

---

Strange you can get to muarae1 through e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99) but not the others;

I think you can get through to all of them, but only muarae1 is configured to reveal its name in response to a tracert probe.

This is true. Or even on the router's viewpoints, this is completely logical to explain.

A few years ago, I was going through the CCNA/CCNP program (got my CCNA cert, took two of the four classes for P, and that's as far as I went) and on the routers, you can set up Access Control Lists (ACLs). One of the main things we did in the configuration assignments were to block certain types of traffic from certain areas of multiple networks. For example, on one router, have it completely drop all incoming ping traffic, but allow outgoing pings. But that didn't mean that all outside traffic was blocked from accessing anything behind that router, just ping traffic was blocked.

Could be something similar.

As far as the inr-310/311 thing that Richard also mentioned 100+ posts back.. after that upgrade a couple months ago, that was one of the first things I noted when we were waiting for the Cricket graphs to come back. We used to be on inr-210/211, and it looks like the upgraded routers just moved up into the 300s, basically. I'm pretty sure I mentioned all of this way back then.

As far as the route changing from 310 to 311 and different ports on each every time you try to trace the route, that is most likely load-balancing efforts, and it would not surprise me at all if there are redundant paths to at least the switch in the rack for all the servers, and it also would not surprise me if there were two switches in the rack and every server has two NICs.

We used redundant paths in one of the CCNP classes and those were fun to set up, but they were also a logical headache at the same time. They aren't difficult to configure, but they are incredibly easy to botch the entire config and it is often difficult to pin-point exactly where it got botched. You can either set up redundant paths to be strictly a fail-over/backup, or you can configure load-balancing, or even link aggregation (taking two 1gbit physical links and turning them into one 2gbit virtual interface on both ends).

Networking is really fun to design, then configure (when you know how to do it and aren't referring to tutorials you found on Google), and then see them in action. Diagnosing what went wrong is not fun at all, especially when you can't just wipe the configuration and start over, because then everything would be unreachable for everyone in the time that you're attempting to re-configure everything from scratch. Doing it live is difficult, and often.. does not yield the expected result because some part of what was done actually needs the device to be power cycled.

What could be done in this case, since it appears there are redundant paths, is to unplug one of them, start over from scratch on that one, then bring it back online, make sure it works, then do the same with the other one.. but then there's no guarantee that once the two are back up and running, they'll mesh together as expected.. which I'm thinking is probably what's going on here.



Just my humble opinion on this topic. Load balancing is probably the main part of the problem, and either it needs to be configured to be primary and fail-over, or configure it to be aggregated. Load balancing and changing the route frequently can be very confusing..especially for dynamic routing tables.

[edit: I seem to recall, actually, that before the upgrade, we were primarily on 210 or 211 99% of the time. Something would go wrong, and we'd end up on the other one instead, until the problem was fixed, and then it would switch back over. So in the old setup, it was configured to be primary and fail-over.]

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Every Traceroute I've run has setiboinc.ssl.berkeley.edu at et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103). Not a single one has listed e3-47.inr-310-ewdc.berkeley.edu (128.32.0.99). My hosts are at least Reporting and Receiving New tasks.

traceroute to setiboinc.ssl.berkeley.edu (208.68.240.126), 64 hops max, 72 byte packets
1 192.168.1.1 (192.168.1.1) 1.666 ms 0.606 ms 0.781 ms
2 l100.tampfl-vfttp-76.verizon-gni.net (96.254.233.1) 7.174 ms 8.901 ms 10.100 ms
3 g0-5-5-0.tampfl-lcr-22.verizon-gni.net (130.81.110.228) 11.500 ms 10.079 ms 12.789 ms
4 * * *
5 0.ae4.br1.mia19.alter.net (140.222.225.113) 18.032 ms 17.305 ms 17.049 ms
6 lag-10.ear2.miami2.level3.net (4.68.71.169) 17.428 ms 17.632 ms 16.927 ms
7 ae-31-51.ebr1.miami1.level3.net (4.69.138.91) 70.303 ms 69.155 ms 70.168 ms
8 ae-2-2.ebr1.dallas1.level3.net (4.69.140.133) 69.709 ms 69.627 ms 69.629 ms
9 ae-71-71.csw2.dallas1.level3.net (4.69.151.137) 70.462 ms 69.286 ms 71.636 ms
10 ae-73-73.ebr3.dallas1.level3.net (4.69.151.146) 68.158 ms 69.769 ms 69.919 ms
11 ae-3-3.ebr2.losangeles1.level3.net (4.69.132.77) 70.177 ms 69.205 ms 70.195 ms
12 ae-82-82.csw3.losangeles1.level3.net (4.69.137.26) 69.657 ms 70.028 ms 69.699 ms
13 * ae-3-80.ear1.losangeles1.level3.net (4.69.144.146) 69.485 ms 69.877 ms
14 cenic.ear1.losangeles1.level3.net (4.35.156.66) 69.468 ms 69.842 ms 69.686 ms
15 dc-svl-agg4--lax-agg6-100ge.cenic.net (137.164.11.1) 77.642 ms 77.237 ms 77.203 ms
16 dc-oak-agg4--svl-agg4-100ge.cenic.net (137.164.46.144) 79.922 ms 79.436 ms 79.925 ms
17 ucb--oak-agg4-10g.cenic.net (137.164.50.31) 80.151 ms 79.493 ms 79.917 ms
18 t2-3.inr-202-reccev.berkeley.edu (128.32.0.39) 79.914 ms 79.305 ms 80.097 ms
19 et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103) 79.923 ms 79.376 ms 79.928 ms
20 et3-47.inr-311-ewdc.berkeley.edu (128.32.0.103) 1572.485 ms !H * 1071.638 ms !H

The only suggestion from that point forward is abuse of the update button.

Or drowning your sorrows in a pint of beer, which it where I'm heading now. Time out.

This worked!

---

yeah same traceroute as everyone else

Sorry Zombu2, I should have made it simpler:

Here is a tracert from one of my boxes that has NOT been connecting...

>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.


>tracert setiathome.berkeley.edu

Tracing route to setiathome.berkeley.edu [208.68.240.110]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms xxx
2 * * * Request timed out.
3 22 ms 31 ms 31 ms xxx
4 12 ms 12 ms 10 ms xxx
5 14 ms 13 ms 15 ms xxx

6 28 ms 29 ms 29 ms bu-ether15.chcgildt87w-bcr00.tbone.rr.com [66.10
9.6.72]
7 33 ms 26 ms 28 ms 0.ae1.pr1.chi10.tbone.rr.com [107.14.17.194]
8 36 ms 27 ms 28 ms xe-4-2-0.0.chic0.tr-cps.internet2.edu [64.57.20.
53]
9 26 ms 26 ms 27 ms ae-5.80.rtr.chic.net.internet2.edu [64.57.20.150
]
10 39 ms 37 ms 36 ms ae-0.80.rtr.kans.net.internet2.edu [64.57.20.148
]
11 76 ms 93 ms 78 ms ae-0.80.rtr.salt.net.internet2.edu [64.57.20.146
]
12 72 ms 78 ms 73 ms ae-2.80.rtr.losa.net.internet2.edu [64.57.20.144
]
13 79 ms 78 ms 77 ms xe-0-0-0.80.rtr.paix.net.internet2.edu [64.57.20
.125]
14 78 ms 78 ms 78 ms 64.57.21.7
15 79 ms 81 ms 81 ms dc-oak-agg4--svl-agg4-100ge.cenic.net [137.164.4
6.144]
16 80 ms 82 ms 82 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31]
17 81 ms 83 ms 81 ms t2-3.inr-202-reccev.Berkeley.EDU [128.32.0.39]
18 82 ms 82 ms 87 ms e3-47.inr-310-ewdc.Berkeley.EDU [128.32.0.99]
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.

Trace complete.


And here is a tracert from one of my boxes that has been connecting...

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

>tracert -h 20 -w 15001 setiathome.berkeley.edu

Tracing route to setiathome.berkeley.edu [208.68.240.110]
over a maximum of 20 hops:

1 <1 ms <1 ms <1 ms xxx
2 3 ms 4 ms 4 ms xxx
3 7 ms 7 ms 7 ms xxx
4 * * * Request timed out.
5 * * * Request timed out.
6 16 ms 16 ms 15 ms 0.ae2.BR3.NYC4.ALTER.NET [140.222.229.99]
7 * * * Request timed out.
8 75 ms 74 ms 74 ms ae-3-80.ear1.SanJose1.Level3.net [4.69.152.150]
9 * * * Request timed out.
10 73 ms 73 ms 73 ms CENIC.ear1.SanJose1.Level3.net [4.15.122.46]
11 74 ms 75 ms 74 ms dc-oak-agg4--svl-agg4-100ge.cenic.net [137.164.46.144]
12 75 ms 81 ms 76 ms ucb--oak-agg4-10g.cenic.net [137.164.50.31]
13 75 ms 74 ms 74 ms t2-3.inr-201-sut.Berkeley.EDU [128.32.0.37]
14 75 ms 75 ms 74 ms et3-48.inr-311-ewdc.Berkeley.EDU [128.32.0.101]
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.

Trace complete.

Note that they have not one single node in common.

---

Member of the 20 Year Club

According to David the routing problem is fixed.
Or maybe that's just the routing to the BOINC Domain, as I still can't report my (now) 38 results.

---

yeah same traceroute as everyone else

Sorry Zombu2, I should have made it simpler:

Here is a tracert from one of my boxes that has NOT been connecting...

Trace complete.

You're tracing to the website in both cases, which has no bearing on whether you can "connect" a cruncher to a server. You would need to trace to one of the other data servers (upload, download, scheduling - wherever the problem is) to get any insight into that.

yeah same traceroute as everyone else

Sorry Zombu2, I should have made it simpler:

Here is a tracert from one of my boxes that has NOT been connecting...

Trace complete.

You're tracing to the website in both cases, which has no bearing on whether you can "connect" a cruncher to a server. You would need to trace to one of the other data servers (upload, download, scheduling - wherever the problem is) to get any insight into that.

Yes, I noticed that in the preceding discussions and was about to try it, but just wanted to clarify that what I had previously posted was not "the same"

---

Member of the 20 Year Club