My good old NETGEAR GS108 8-port GigE switch died overnight (2012-02-27/28). This Sunday, 26th, I was watching some Showtime VoD on U-verse, and noticed some occasional packet loss, which, apparently, completely interrupts the stream with U-verse PoS STB. Also the packet loss was present at the very same time on my laptop, trying to ping www.google.com, but was very-very minimal.
What I thought AT&T was to blame, seems like the switch was responsible for.
I honestly didn’t know that switches can fail. :-) It lasted a few years, got it back in North Carolina prior to my grad studies in Canada.
Supposedly, NETGEAR has a lifetime warranty on these ProSafe switches, so, I’ll take a look if it can still be replaced.
written for, and discussion at, http://www.tunnelbroker.net/forums/index.php?topic=2293.0
It would appear that AT&T has quietly added IPv6 support through 6rd for, seemingly, ALL of its customers without telling anyone (specifically, without telling any of the said customers).
All existing customers “are not affected” and don’t know about any such support, since it’s not actually supported by most CPE.
Details are here:
http://www.dslreports.com/forum/r26841639-
If you have Motorola NVG510, it’s enabled by default (yes, that’s how we, the customers, found out!). If you have 2Wire PoS, you can still play around and have it configured through your own equipment (and your equipment doesn’t even has to have 6rd support, e.g. OS X and OpenBSD would do just fine for basic 6rd IPv6 connectivity).
Basically, [b]2602:300::/28[/b] (6rdPrefix/6rdPrefixLen) and [b]12.83.49.81[/b] (6rdBRIPv4Address, which is an anycast) is all you need to get it running, IPv4MaskLen is 0 (use the whole IPv4 address within IPv6, but notice that due to 6rdPrefixLen being /28 (instead of the more conventional /32) you have to do some one-nibble shifting, but the plus side is that you do get a /60 in the end). Plus [b]74.82.42.42[/b] (ordns.he.net.), of course. :-) You can also try the standard dnsr{1,2}.sbcglobal.net, but they have a few problems: http://www.dslreports.com/forum/r26902814-IPv6-6rd-DNS-Cannot-resolve-IPv6-only-zones.
This 6rd from AT&T works great in the Bay Area, but I’ve heard that IPv4-wise, Los Angeles gets routed through San Jose, which is a bummer, since IPv6-wise, HE.net is routed through Los Angeles from San Jose AT&T, hence it would appear like people in LA would have to make three full roundtrips (LA -> SJ over IPv4 (1 round), then SJ -> LA -> SJ over IPv6 (2 rounds)) to reach HE’s FMT IPv6 resources over this 6rd. :-)
[b]This is a must-try if you’re on AT&T![/b]
Here’s a collection of my traceroute6’s:
http://www.dslreports.com/forum/r26907835-IPv6-latency-BayArea-Local-IPv6-around-San-Jose-
Just in case you don’t care for external links:
[code]
% traceroute6 www.google.com
Wed 22 Feb 2012 18:38:09 PST
traceroute6 to www.l.google.com (2001:4860:4001:801::1011) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.579 ms 1.368 ms 1.309 ms
2 sj2ca404me3.ip.att.net (2001:1890:ff:ffff:12:122:119:192) 4.014 ms 4.042 ms 4.007 ms
3 2001:1890:c00:8c02::1116:e9cb (2001:1890:c00:8c02::1116:e9cb) 54.538 ms 55.262 ms 55.846 ms
4 2001:4860::1:0:21 (2001:4860::1:0:21) 5.572 ms 5.374 ms 5.154 ms
5 2001:4860:0:1::1af (2001:4860:0:1::1af) 5.425 ms 5.55 ms 5.343 ms
6 2001:4860:8000:e:92e6:baff:fe53:a202 (2001:4860:8000:e:92e6:baff:fe53:a202) 56.341 ms 57.198 ms 56.167 ms
[/code]
Here’s my traceroute / mtr to the 6rdBRIPv4Address:
[code]
% traceroute -I 12.83.49.81
Wed 22 Feb 2012 18:47:16 PST
traceroute to 12.83.49.81 (12.83.49.81), 32 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.581 ms 1.700 ms 1.568 ms
6 12.83.49.81 (12.83.49.81) 1.311 ms 1.310 ms 1.107 ms
% mtr -c60 —report{,-wide} 12.83.49.81
Wed 22 Feb 2012 18:49:30 PST
HOST: 99-124-xxx-xxx.uvs.sntcca.sbcglobal.net Loss% Snt Last Avg Best Wrst StDev
1.|— 99-124-xxx-xxx.uvs.sntcca.sbcglobal.net 0.0% 60 0.8 0.4 0.3 0.8 0.1
2.|— 76-220-32-3.lightspeed.sntcca.sbcglobal.net 76.7% 60 2.2 2.5 1.9 5.1 0.9
3.|— 71.145.0.104 98.3% 60 3.3 3.3 3.3 3.3 0.0
4.|— 71.145.0.80 96.7% 60 6.7 6.8 6.7 6.9 0.1
5.|— 12.83.39.137 0.0% 60 1.7 2.1 1.7 2.8 0.2
6.|— 12.83.49.81 0.0% 60 1.6 1.4 1.2 1.6 0.1
[/code]
Here’s traceroute6 to he.net and back (as I mentioned, it goes SJC -> LAX -> FMT, since LA is the closest point where HE and AT&T do IPv6 peering):
[code]
% traceroute6 ns2.linode.com
Wed 22 Feb 2012 19:07:19 PST
traceroute6 to ns2.linode.com (2600:3c01::a) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.579 ms 1.2 ms 1.315 ms
2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 129.526 ms 13.831 ms 24.7 ms
3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 13.755 ms 13.938 ms 13.77 ms
4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 13.843 ms 13.829 ms 13.787 ms
5 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18d::1) 24.908 ms 21.798 ms 21.9 ms
6 gige-g4-18.core1.fmt1.he.net (2001:470:0:2d::1) 22.01 ms 21.99 ms
linode-llc.10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::2) 22.852 ms
7 ns2.linode.com (2600:3c01::a) 22.439 ms 22.319 ms 22.335 ms
[/code]
[code]
# traceroute6 2602:306:37cY:YYY0::1
traceroute to 2602:306:37cY:YYY0::1 (2602:306:37cY:YYY0::1), 16 hops max, 80 byte packets
2 10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::1) [AS6939] 5.666 ms 5.782 ms 5.760 ms
3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) [AS6939] 0.454 ms 0.443 ms 0.532 ms
4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) [AS6939] 8.514 ms 8.500 ms 8.474 ms
5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) [AS6939] 15.265 ms 8.905 ms 14.903 ms
6 att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::2) [AS6939] 8.915 ms 8.988 ms 9.052 ms
7 * * *
8 * * *
9 2001:1890:ff:ffff:12:122:114:41 (2001:1890:ff:ffff:12:122:114:41) [AS7018] 22.141 ms 22.114 ms 22.078 ms
10 2602:300:c533:1510::5 (2602:300:c533:1510::5) [*] 21.171 ms 21.174 ms 21.148 ms
11 * * *
12 * * *
13 * * *
14 2602:300:c533:1510::6 (2602:300:c533:1510::6) [*] 22.154 ms 22.425 ms 22.649 ms
15 2602:300:c533:1510::5 (2602:300:c533:1510::5) [*] 22.280 ms 22.709 ms 23.197 ms
16 2602:306:37cY:YYY0::1 (2602:306:37cY:YYY0::1) [*] 22.543 ms 22.710 ms 23.209 ms
[/code]
Try the following to get your IPv6 prefix from the IPv4 address:
[code]
% printf “%02x%02x%02x%02x” 99 124 xxx xxx | awk ‘{print “2602:30” substr($1,1,1) “:” substr($1,2,4) “:” substr($1,6) “0::/60”}’
2602:306:37cY:YYY0::/60
[/code]
What would be interesting to know are the locations of where 6rdBR’s have been deployed. So far, it’s known that LA uses the one in San Jose, so there doesn’t appear to be a 6rdBR in LA. You can guesstimate the location of your 6rdBR by doing `traceroute 12.83.49.81` from your local AT&T network, or by doing a traceroute6 of your 6rd IPv6 address from a remote network, seeing the latency of the last hop of the 2602:300:c533:1510::/60 origin (which is, you’ve guessed it, the anycast 6rd prefix of the 6rdBR’s 12.83.49.81). Your total latency for a given IPv6 resource over this 6rd would be the sum of these two latencies around the 6rdBR anycast (12.83.49.81 / 2602:300:c533:1510::/60).
Happy 6rd tunnelling!
P.S. I should warn you that this whole info is based solely on user-submitted “reverse-engineered” information. I should also warn you that if you ever decide to go to AT&T’s corporate IPv6 web-site (the link for which is very short and memorable, but is intentionally omitted from this post such as to not waste people’s time), that you will not find a single useful piece of information about anything whatsoever, and the time that you will lose you’ll never get back! (-:
It’s funny how the rank and seniority within a given organisation or community is not necessarily attached to the person, but to the person solely within the context of the said organisation.
What happens when you switch or are on a visit elsewhere? What’s the best way to take your achieved “rank” and seniority with you? Regardless of the new community — be that study, workplace or online — it seems like in the vast majority of cases, you’d have to spend at least a few days, weeks, months, or maybe even years, being “that guy who only showed up here XX days ago”; not necessarily from the point of view of everyone in a given org, but at the very least from the PoV of some individual members of the new group.
However, since there are so many idiots around everywhere, it’s hardly surprising that it happens just like that… Perceived rank and seniority must be earned individually within a given group. Fast-tracking is obviously highly common, but, IMHO, outright and immediate acceptance is a myth.
http://uptime.netcraft.com/up/graph?site=www.firstvds.ru
Какой позор! Перешли на CloudFlare, вот смеху-то! Хостер, называется!
Собственно, совершенно не удивительно: как оказалось, на их глючной ISPFreeBSD8 нет поддержки динамических правил ipfw, т.е. “keep-state” и “limit” работать не будут! И от “setup” тоже толку нет! Из-за этих мудаков я в январе потратил несколько часов на написания правил ipfw для нового сервера на ISPFreeBSD8, которые абсолютно на их сломанной виртуализации не работают! Без динамических (keep-state) правил, полностью все правила нужно переписывать с нуля, с абсолютно другой ментальностью! А потом ещё окажется, что их говёная исковерканная фря ещё чего-нибудь не поддерживает!
В добавок, их NS-сервера постоянно глючат. Несколько раз проверял ns2.firstvds.ru, `dig @ns2.firstvds.ru`, как мои домены, так и сам firstvds.ru. Постоянно записи на половину доменов отсутствует! Только ns1.firstvds.ru выдаёт записи! Честное слово, что за дерьмовым провайдером я пользуюсь уже который год?
Just found a seemingly absolutely great VPS provider I’ve never ever heard of before: www.vr.org! Last result on google for ‘FreeBSD VPS’ on the first page — http://www.vr.org/os/bsd-hosting/freebsd-vps . Their price structure is similar to Linode, but they start out at 256MB/10GB/200GB with 2 CPUs at only 9,99 USD. Have a Looking Glass, many DCs all over the world, including San Jose andwww.vr.org! Last result on google for ‘FreeBSD VPS’ on the first page — http://www.vr.org/os/bsd-hosting/freebsd-vps . Their price structure is similar to Linode, but they start out at 256MB/10GB/200GB with 2 CPUs at only 9,99 USD. Have a Looking Glass, many DCs all over the world, including San Jose and Los Angeles, IPv6 support at each DC, and are even based out of San Jose, CA! Plus, www.vr.org, how cool is that? ;-)
vr.org seemed to have started offering FreeBSD only about last year or so, maybe that’s why I haven’t heard of them yet. However, I’m still amazed that I’ve never heard of such a huge global hosting operation.
Another interesting provider that is nqhost.com, based out of Eastern Europe (.cz), that started out just a couple of years ago, with some servers in the US, Germany and Russia. http://nqhost.com/freebsd-vps.html / http://ru.nqhost.com/freebsd-vps.html . 512MB/30GB/unmetered for 15 USD is a good deal, and, according to the Russian page, they do give out two CPUs! Supposedly, they do offer IPv6 on at least some locations (.de only, according to a support ticket), but they don’t officially advertise it. No West Coast locations.
I started In-N-Out with a cheeseburger and a fries. Since I usually have just water to drink, I’ve switched to two cheeseburgers, triple-extra tomato, well-done, plus fries—light.
However, it was kinda a bit heavy, and looking over at the Nutrition Facts, 25 grams of saturated fat, where the daily intake is supposed to be 20 g.
Way to make it healthier?
0. Cheese. Turns out, American cheese (or perhaps milk/cream in general), is pretty bad for you, having 0.5g of trans-fat (regular burger has none), plus 5 g of “Saturated Fat” (regular burger has 5 g in itself, yet cheeseburger is 10 g), plus almost 1/3rd more extra “Total Fat”. Not much extra protein, either; zero extra carbs. No cheese for me!
1. Spread. Lots of “Total Fat” (not to be confused with merely saturated fat). We’re no-cheese now, so: the burger with spread: 19 g, without 10g. Wha-ha! No extra protein whatsoever, no extra carbs, just pure extra fat! And a heavy feeling in the stomach! No spread for me!
So, in the end, to get more protein intake than from two cheeseburgers, you can afford 3 hamburgers “with mustard & ketchup instead of spread” (“M K Inst”), and still have lots of room left fat-wise! Protein is good for muscle build up when you work out, whereas carbs are good for energy to do the work out.
For me, since one cheseburger was too little, and two were too much (especially fat-wise with a heavy stomach feeling), I decided to be going with just two burgers, “M K Inst”. About the same protein intake as two CHB, but LOWER fat intake than a single one CHB! Frankly, it even tastes better (can taste the great western US 100% pure beef patty), and obviously doesn’t clog your arteries.
My new total order is:
2 HAMB
W X X X T K M Inst Well
WO X X X T K M Inst Well
FF light
Amount Due $5.95
This leaves me with:
Total Fat: 2 * 10 + 18 = 38 g (previous 2 CHB order: 2 * 27 + 18 = 77g, oh-oh)
Saturated Fat: 2 * 4 + 5 = 13 g (daily limit is 20g, previous 2CHB was over by 5g (2*10 + 5 = 25g), this one is lower by 7g!)
Carbohydrates: 2 * 41 + 54 = 136 g (previous 2CHB: about the same, 132g)
Protein: 2 * 16 + 7 = 39g (previous 2 CHB: 2 * 22 + 7 = 51g; new alternative 3 HAMB: 3 * 16 + 7 = 55g)
So, notice how you could have 2 “HAMB K M Inst” instead of 2 CHB for about the same carb and protein intake (for exercise energy and post-exercise muscle-build-up), yet less than half the fat, or 3 “HAMB K M Inst” instead of 2 CHB for much-higher protein intake, yet still less fat!
Thing is, regular burgers even taste better. I know I made my choice, and I rest the case. :-)
I’ve been watching Undercover Boss on CBS VoD in the last month or so, and I have formed several very strong impressions that are evident throughout the series.
0. “Overpaid” individuals like the CEOs have absolutely zero skills to do the low-paid level jobs. Seriously. I highly doubt I myself could ever be successful at flipping burgers or getting the pool clean, 10 hours a day, 6 days a week. I might do a good job, but I’d be too damn slow at it for sure. The CEOs indeed show that they’re absolutely horrible about it. Probably, the more “overpaid” you are, the worse you’d be at doing the lower-level jobs. :-)
1. Being an engineer myself, the series brings to light the working conditions of regular Americans. Some of it is already known through the day-to-day interaction with various staff members of various hospitality establishments, but some shine extra new light of just how horrible the working conditions of some people are.
1a: Diamond Resorts International (resorts/hotels/hospitality) episode: The episode showed an example of a single one of the operations being: underpaid, understaffed, overworked and lacking proper equipment and tools, and also even lacking appropriate safety precautions (no proper safety masks, WTF?). What do they do to rectify all of this? They just claim to give that very single operation the resources that it should have had in the first place, plus the rewards to the poor folk that happened to be the “trainer” of the CEO, and call it a day. WTF?
1b: The Kendall-Jackson (winery) episode. Someone in their retail branch works 40 hours a week as a part-time employee with no benefits. Seriously, WTF? How could they possibly, “by mistake”, hire someone to work 40 hours per week as a part-time employee? How does this even fit within the legal framework; surely it must be illegal per California law to hire someone parttime at a fulltime job, working over 40 hours per week, shouldn’t it be? IMHO, this just shows how horrible the system is. The rectification? Full-time promotion of the single affected individual. What about the rest of the people? Completely left out.
1c: The Checkers (southern/east-coast fast-food chain) episode. They literally closed down the whole restaurant after finding out that not a single person within the operation has received any training, the manager was being an arsehole (seriously, how could someone be so stupid to let that one slip on the camera?), and that most buttons on the grills and such were mislabelled. WTF? However, having dined in the McD over here in the US after honestly enjoying it back in Canada, I can say that I’m hardly surprised: McD in California is the worst place ever, and I will never step my foot into one again. (The one over here in Midtown San Jose has once made 5 mistakes on my 4-item order; when I asked for the manager, it was revealed that the stupid employee who made all the mistakes was in fact the manager, who offered no apology, either.) I miss my Canadian McDs.
2. It’s nice that they with these series help out these poor people, who work their arses off at these low-paid jobs, however, what happens to the person next to those being helped? What does it feel coming to the low-paid job, after you have “won the lottery”? How do the colleagues react to interacting with their peers who have happened to have “won the lottery”?
I think as a viewer and potential customer of these establishments, some of which I haven’t even heard of before, it is certainly to be appreciated that the CEOs have allowed this kind of exposure into their business. However, on the other side, I find the “rewards” and the “fixes” they present in the series to be rather superficial. In my opinion, the whole series is rather depressing to watch, as you quickly realise how horrible the working conditions of some of our neighbours are…
I’m on AT&T’s IPv6 network in San Jose, CA, and I’m trying to find the best edge nodes latency-wise. Here’s what I have so far, California-wise.
% alias traceroute6 traceroute6 -w2 -l % traceroute6 ipv6.akamai.com traceroute6 to a152.i6g1.akamai.net (2600:5:3700:2::c703:730b) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.863 ms 1.149 ms 1.304 ms 2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 8.013 ms 3.031 ms 3.605 ms 3 2001:1890:1fff:404:192:205:35:18 (2001:1890:1fff:404:192:205:35:18) 5.989 ms 21.109 ms * 4 2600:5:3700:2::c703:730b (2600:5:3700:2::c703:730b) 5.248 ms 7.884 ms 5.317 ms % alias postcmd date % traceroute6 ipv6.akamai.com Fri 17 Feb 2012 12:13:45 PST traceroute6 to a152.i6g1.akamai.net (2001:559:0:301::6011:6d48) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.701 ms 1.306 ms 1.336 ms 2 sfcca03jt.ip.att.net (2001:1890:ff:ffff:12:122:126:243) 3.134 ms 2.941 ms 3.006 ms 3 2001:1890:1fff:400:192:205:37:2 (2001:1890:1fff:400:192:205:37:2) 9.998 ms 7.029 ms 7.734 ms 4 pos-2-2-0-0-cr01.sanjose.ca.ibone.comcast.net (2001:558:0:f58d::1) 10.499 ms 12.967 ms 10.206 ms 5 pos-0-4-0-0-pe01.529bryant.ca.ibone.comcast.net (2001:558:0:f5e4::2) 9.635 ms 8.965 ms 8.941 ms 6 2001:559::16 (2001:559::16) 11.532 ms 8.532 ms 8.35 ms 7 2001:559:0:301::6011:6d48 (2001:559:0:301::6011:6d48) 8.428 ms 8.403 ms 8.437 ms % traceroute6 www.limelight.com Fri 17 Feb 2012 12:14:09 PST traceroute6 to llnw.vo.llnwd.net (2607:f4e8:110:104:230:48ff:fe87:3054) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.613 ms 1.336 ms 1.281 ms 2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 2.917 ms 3.037 ms 2.898 ms 3 2001:450:2008:100::109 (2001:450:2008:100::109) 70.089 ms 70.23 ms 70.255 ms 4 2001:450:2002:2c6::2 (2001:450:2002:2c6::2) 16.898 ms 24.493 ms 13.562 ms 5 ve4.fr3.snv1.ipv6.llnw.net (2607:f4e8:1:a4::2) 14.659 ms 20.964 ms 14.185 ms 6 cds205.sjc.llnw.net (2607:f4e8:110:104:230:48ff:fe87:3054) 15.343 ms 15.902 ms 16.278 ms % traceroute6 ipv6.google.com Fri 17 Feb 2012 12:14:35 PST traceroute6 to ipv6.l.google.com (2001:4860:4001:800::1011) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.749 ms 1.173 ms 1.346 ms 2 sj2ca404me3.ip.att.net (2001:1890:ff:ffff:12:122:119:192) 4.048 ms 3.999 ms 4.059 ms 3 2001:1890:c00:8c02::1116:e9cb (2001:1890:c00:8c02::1116:e9cb) 50.029 ms 48.965 ms 47.51 ms 4 2001:4860::1:0:21 (2001:4860::1:0:21) 5.225 ms 5.96 ms 5.481 ms 5 2001:4860:0:1::1ab (2001:4860:0:1::1ab) 5.381 ms 5.204 ms 5.305 ms 6 2001:4860:4001:800::17 (2001:4860:4001:800::17) 54.298 ms 53.502 ms 53.744 ms % traceroute6 ns2.he.net Fri 17 Feb 2012 12:15:46 PST traceroute6 to ns2.he.net (2001:470:200::2) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.601 ms 1.266 ms 1.283 ms 2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 13.73 ms 13.632 ms 13.996 ms 3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 18.977 ms 13.617 ms 13.708 ms 4 10gigabitethernet7-3.core1.sjc2.he.net (2001:470:0:16a::1) 22.056 ms 24.109 ms 24.928 ms 5 ns2.he.net (2001:470:200::2) 22.112 ms 22.085 ms 21.968 ms % traceroute6 www.ixsystems.com Fri 17 Feb 2012 12:16:38 PST traceroute6 to web.ixsystems.com (2607:fca8:2636:8001::4) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.629 ms 1.233 ms 1.183 ms 2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 14.812 ms 13.473 ms 13.863 ms 3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 14.281 ms 15.176 ms 13.682 ms 4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 13.531 ms 18.466 ms 20.744 ms 5 2607:fca8:1530::1 (2607:fca8:1530::1) 13.688 ms 13.865 ms 13.782 ms 6 2607:fca8:2636:8001::4 (2607:fca8:2636:8001::4) 14.136 ms 14.481 ms 14.672 ms % traceroute6 www.arpnetworks.com Fri 17 Feb 2012 12:17:02 PST traceroute6 to www.arpnetworks.com (2607:f2f8:0:102::3) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.74 ms 1.222 ms 1.182 ms 2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 113.136 ms 3.134 ms 2.922 ms 3 2001:450:2008:100::109 (2001:450:2008:100::109) 150.088 ms 2001:450:2008:100::c5 (2001:450:2008:100::c5) 69.797 ms 70.066 ms 4 * * * 5 2607:f2f8:100:105::1 (2607:f2f8:100:105::1) 14.123 ms 14.058 ms 14.096 ms 6 www.arpnetworks.com (2607:f2f8:0:102::3) 14.616 ms 14.429 ms 14.47 ms % traceroute6 obsd.isc.org Fri 17 Feb 2012 12:20:22 PST traceroute6 to obsd.isc.org (2001:4f8:3:36::217) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.753 ms 1.213 ms 1.905 ms 2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 2.957 ms 4.544 ms 3.373 ms 3 2001:1890:1fff:40d:192:205:33:50 (2001:1890:1fff:40d:192:205:33:50) 4.895 ms * 5.069 ms 4 chi-bb1-v6.telia.net (2001:2000:3018:2c::1) 55.734 ms 55.583 ms 55.652 ms 5 isc-ic-117366-chi-bb1.c.telia.net (2001:2000:3080:138::2) 55.852 ms 56.083 ms 56.078 ms 6 int-0-0-1-8.r1.pao1.isc.org (2001:4f8:0:1::4a:1) 108.838 ms 108.864 ms 110.633 ms 7 int-0-1-0-0.r1.sql1.isc.org (2001:4f8:1b:1::8:2) 112.205 ms 108.617 ms 109.507 ms 8 2001:4f8:3:36::217 (2001:4f8:3:36::217) 108.234 ms 107.538 ms 108.512 ms
So far, the now-disappeared DNS resolution of ipv6.akamai.com over at Sprint seemed to have had the best latency earlier this morning, of only 5.3ms.
IPv4-wise, I can still get 3.7ms to some CDN host at nlayer.net (see http://www.dslreports.com/forum/remark,26669632 and the traceroute below), so, I’m thinking that something around 4ms should be entirely possible with IPv6, too.
% traceroute -I 69.22.162.122 Fri 17 Feb 2012 12:41:33 PST traceroute to 69.22.162.122 (69.22.162.122), 32 hops max, 60 byte packets 5 12.83.39.145 (12.83.39.145) 16.198 ms 2.141 ms 1.800 ms 6 ppp-151-164-52-233.rcsntx.swbell.net (151.164.52.233) 99.646 ms 207.202 ms 5.913 ms 7 asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70) 5.041 ms 4.636 ms 4.421 ms 8 69.22.162.122 (69.22.162.122) 3.802 ms 3.792 ms 3.710 ms
Any ideas what other IPv6 hosts are in the Bay Area that could have good latency with AT&T’s IPv6 network?
written for, and discussion at, http://www.dslreports.com/forum/r26907835-IPv6-latency-BayArea-Local-IPv6-around-San-Jose-
There seems to be a bit of confusion over which DNS servers the IPv6-enabled customers are supposed to be using. I found that using the regular recursive DNS servers (-4 dnsr{1,2}) from the non-IPv6-enabled-2Wire directly on my OS X does work on resolving AAAA records, but ONLY if the auth NS servers for the domain zone in question are available over IPv4.
Please note that in the scope of this discussion, an “IPv6-only domain” is a domain name that can be resolved ONLY via an IPv6 network, since the NS servers of the zone in question are available ONLY via IPv6. A more correct term would probably be a “domain name within an IPv6-only domain zone”.
Surprisingly, using dns6rd{1,2} does NOT resolve IPv6-only domains, i.e. those that require IPv6 to access its auth NS servers. Making it pretty obvious that dns6rd{1,2} are NOT dual-stacked. WTF? So useless! What’s the purpose of the dns6rd servers if they can’t access IPv6-only domain zones, where the regular dnsr{1,2} already work for AAAA as is?
Seems like dns6rd{1,2} are already EOL at this point, as they offer no advantage whatsoever over -4 dnsr{1,2}, and there’s not even any -6 dns6rd{1,2}, plus they don’t seem to be much of anycast, either.
Using the -6 dnsr{1,2} does resolve IPv6-only domains, but the servers are very far away from me, so they’ll be breaking all those unicast DNS-based CDNs in a snap (e.g. Google, Akamai etc).
Is there an ETA on when either my -4 dnsr{1,2} anycast would be dual-stacked, or the -6 dnsr{1,2} would be anycast’ed locally, instead of going back to Texas or whatnot?
Here are my sample traceroute runs from San Jose, CA. (Note that there’s no -6 dns6rd{1,2}, as already mentioned above.)
[code]
% echo traceroute{\ -IM5,6\ -l}\ -w2\ dns{r,6rd}{1,2}.sbcglobal.net | xargs -n4 | sh
traceroute to dnsr1.sbcglobal.net (68.94.156.1), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.464 ms 2.178 ms 1.997 ms
6 151.164.102.35 (151.164.102.35) 3.796 ms 3.268 ms 3.058 ms
7 dnsr1.sbcglobal.net (68.94.156.1) 3.347 ms 2.834 ms 3.005 ms
traceroute to dnsr2.sbcglobal.net (68.94.157.1), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.155 ms 1.865 ms 1.857 ms
6 dist1-10g1-2.snfcca.sbcglobal.net (216.102.176.225) 3.463 ms 4.992 ms 3.052 ms
7 dnsr2.sbcglobal.net (68.94.157.1) 3.343 ms 3.147 ms 3.004 ms
traceroute to dns6rd1.sbcglobal.net (99.99.99.53), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.051 ms 1.846 ms 1.838 ms
6 12.83.49.11 (12.83.49.11) 44.498 ms 44.029 ms 44.040 ms
7 ppp-151-164-39-47.rcsntx.swbell.net (151.164.39.47) 44.457 ms 43.917 ms 46.538 ms
8 dns6rd1.sbcglobal.net (99.99.99.53) 44.564 ms 44.067 ms 44.076 ms
traceroute to dns6rd2.sbcglobal.net (99.99.99.153), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.059 ms 1.907 ms 1.769 ms
6 bb2-p2-0.snantx.sbcglobal.net (151.164.42.128) 44.352 ms 43.849 ms 43.905 ms
7 ppp-151-164-39-47.rcsntx.swbell.net (151.164.39.47) 43.946 ms 43.907 ms 43.753 ms
8 dns6rd2.sbcglobal.net (99.99.99.153) 43.984 ms 43.546 ms 43.679 ms
traceroute6 to dnsr1.sbcglobal.net (2001:1890:fff:840::10) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 3.121 ms 2.098 ms 1.968 ms
2 2001:1890:ff:ffff:12:122:100:82 (2001:1890:ff:ffff:12:122:100:82) 47.929 ms 47.989 ms 47.585 ms
3 2001:1890:fff:820:12:122:243:1 (2001:1890:fff:820:12:122:243:1) 47.562 ms 47.671 ms 47.714 ms
4 dnsr1.sbcglobal.net (2001:1890:fff:840::10) 47.718 ms 47.714 ms 47.818 ms
traceroute6 to dnsr2.sbcglobal.net (2001:1890:fff:841::10) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 2.224 ms 1.868 ms 2.016 ms
2 2001:1890:ff:ffff:12:122:100:82 (2001:1890:ff:ffff:12:122:100:82) 47.57 ms 47.429 ms 47.747 ms
3 2001:1890:fff:820:12:122:243:1 (2001:1890:fff:820:12:122:243:1) 47.372 ms 47.382 ms 47.31 ms
4 dnsr2.sbcglobal.net (2001:1890:fff:841::10) 47.834 ms 47.489 ms 47.508 ms
traceroute6: nodename nor servname provided, or not known
traceroute6: nodename nor servname provided, or not known
[/code]
[code]
% traceroute -I 12.83.49.81
traceroute to 12.83.49.81 (12.83.49.81), 32 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.015 ms 1.799 ms 1.976 ms
6 12.83.49.81 (12.83.49.81) 1.908 ms 1.682 ms 1.517 ms
[/code]
written for, and discussion at, http://www.dslreports.com/forum/r26902814-IPv6-6rd-DNS-Cannot-resolve-IPv6-only-zones.
Over at my FTTU and IPv4-wise, my ZyXEL router stopped working around midnight today (2012-02-15T00) for good, and the connexion seemed quite dead when trying to revive it directly at the ONT with an OpenBSD netbook, too. 2Wire PoS has been disconnected for several months, but I guess they do have that crappy authentication going on after all? Had to put the 2Wire PoS back into service, leaving no excuse not to try 6rd.
6rd is quite boring. It just works. :-)
This is on OS X 10.5 (yes, 10.5, which obviously has no 6rd support).
% printf "%02x%02x:%02x%02x\n" 99 124 xxx xxx 637c:YYYY
sudo ifconfig gif0 tunnel 99.124.xxx.xxx 12.83.49.81 sudo ifconfig gif0 inet6 2602:306:37cY:YYY0::1 prefixlen 60 sudo route add -inet6 default -interface gif0
% traceroute -I 12.83.49.81 traceroute to 12.83.49.81 (12.83.49.81), 32 hops max, 60 byte packets 5 12.83.39.137 (12.83.39.137) 3.583 ms 2.173 ms 1.882 ms 6 12.83.49.81 (12.83.49.81) 1.813 ms 1.518 ms 1.540 ms % traceroute6 ns4.linode.com traceroute6 to ns4.linode.com (2600:3c03::a) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 2.209 ms 1.871 ms 1.815 ms 2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 3.612 ms 3.588 ms 3.687 ms 3 2001:1890:1fff:40d:192:205:33:50 (2001:1890:1fff:40d:192:205:33:50) 5.432 ms * 5.567 ms 4 nyk-b2-v6.telia.net (2001:2000:3018:39::1) 77.77 ms 78.044 ms 78.822 ms 5 nac-ic-114014-nyk-b2.c.telia.net (2001:2000:3080:46::2) 76.989 ms 77.049 ms 76.955 ms 6 e1.2.tbr2.mmu.nac.net (2001:518:1001:3::2) 77.676 ms 77.757 ms 77.78 ms 7 Vlan805.esd1.mmu.nac.net (2001:518:2001:5::2) 78.886 ms 80.195 ms 78.718 ms 8 2001:518:2800:3::2 (2001:518:2800:3::2) 78.69 ms 78.849 ms 78.725 ms 9 ns4.linode.com (2600:3c03::a) 78.33 ms 77.946 ms 77.767 ms % traceroute ns4.linode.com traceroute to ns4.linode.com (207.192.70.10), 32 hops max, 40 byte packets 5 12.83.39.137 (12.83.39.137) 3.591 ms 2.302 ms 2.418 ms 6 ppp-151-164-52-233.rcsntx.swbell.net (151.164.52.233) 4.896 ms 4.254 ms 4.098 ms 7 asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70) 6.131 ms 6.476 ms 8.813 ms 8 ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18) 5.656 ms 4.189 ms 4.074 ms 9 ae1-60g.cr1.sfo1.us.nlayer.net (69.22.143.169) 5.371 ms 5.289 ms 5.062 ms 10 xe-1-2-0.cr1.slc1.us.nlayer.net (69.22.142.96) 22.531 ms 22.867 ms 22.016 ms 11 xe-0-3-0.cr1.ord1.us.nlayer.net (69.22.142.101) 56.448 ms 56.244 ms 55.929 ms 12 xe-9-2-0.cr1.ewr1.us.nlayer.net (69.22.142.75) 75.541 ms 75.642 ms 75.418 ms 13 ae1-70g.ar2.ewr1.us.nlayer.net (69.31.94.118) 80.255 ms 79.729 ms 76.732 ms 14 as8001.xe-3-0-6.ar2.ewr1.us.nlayer.net (69.31.95.130) 77.457 ms 76.987 ms 76.975 ms 15 0.e1-2.tbr1.mmu.nac.net (209.123.10.118) 78.117 ms 77.715 ms 78.437 ms 16 vlan803.esd2.mmu.nac.net (209.123.10.30) 78.247 ms 77.647 ms 77.971 ms 17 207.99.53.46 (207.99.53.46) 78.274 ms 77.553 ms 77.599 ms 18 ns4.linode.com (207.192.70.10) 78.482 ms 78.088 ms 78.224 ms % traceroute ns2.linode.com traceroute to ns2.linode.com (65.19.178.10), 32 hops max, 40 byte packets 5 12.83.39.137 (12.83.39.137) 3.102 ms 2.376 ms 2.672 ms 6 12.122.200.9 (12.122.200.9) 3.967 ms 3.606 ms 3.714 ms 7 dcr2-so-3-0-0.washington.savvis.net (192.205.32.46) 6.394 ms 192.205.32.50 (192.205.32.50) 5.996 ms 208.51.134.1 (208.51.134.1) 6.122 ms 8 po1-20G.ar3.SJC2.gblx.net (67.16.134.26) 5.954 ms 188.998 ms 200.258 ms 9 Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net (64.214.174.246) 6.361 ms 6.022 ms 5.615 ms 10 10gigabitethernet1-1.core1.fmt1.he.net (72.52.92.109) 9.235 ms 17.773 ms 6.752 ms 11 linode-llc.10gigabitethernet2-3.core1.fmt1.he.net (64.62.250.6) 10.632 ms 8.125 ms 7.812 ms 12 ns2.linode.com (65.19.178.10) 7.259 ms 6.758 ms 6.698 ms % traceroute6 ns2.linode.com traceroute6 to ns2.linode.com (2600:3c01::a) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets 1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 2.729 ms 1.91 ms 1.766 ms 2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 14.564 ms 14.409 ms 14.385 ms 3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 14.458 ms 15.662 ms 24.833 ms 4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 14.206 ms 14.287 ms 14.391 ms 5 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18d::1) 22.733 ms 23.853 ms 25.081 ms 6 gige-g4-18.core1.fmt1.he.net (2001:470:0:2d::1) 22.758 ms 22.674 ms linode-llc.10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::2) 23.296 ms 7 ns2.linode.com (2600:3c01::a) 22.903 ms 22.875 ms 22.795 ms
Routing to the first and second IPv6 hops is absolutely great, just as good as comparative IPv4 hops. (No bunch of useless hops anymore.)
However, AT&T’s in-network IPv6 routing is oftentimes far from optimal: traffic from AT&T SJC to ISC PAO goes through Chicago, HE FMT through LAX, but other routes are pretty decent.
Out of other possible problems, seems like dns6rd1.sbcglobal.net and dns6rd2.sbcglobal.net are not anycast, so, the unicast-based CDNs seem to suffer greatly from poor DNS resolution. But the 6rd gateway, 12.83.49.81, is definitely anycast, no questions there! I am still coloured impressed. :-) You don’t get 1.5ms tunnel endpoints on residential connexions here and there. :)
written for, and discussion at, http://www.dslreports.com/forum/r26898965-6rd-just-works-indeed-Even-when-your-OS-doesn-t-support-it-