|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Warning: Whiny rant below!
I hate iOS 11. There's nothing I like about it. It makes my iPad (2017 model, 7th generation, whatever you want to call it) much more difficult to use and provides me absolutely no benefits over iOS 10.
Here's a list of useful applications that are no longer supported since they're 32-bit only (indirectly, this is Apple's fault):
Also, there's a bug in iTunes 12.7 that results in all of the tracks from my legally-purchased (albeit manually tagged) music showing up as separate albums. Yes, that makes browsing music by album fairly useless. Other folks are suffering from the same problem but the only solution seems to be to downgrade iTunes, something I can't do because older versions don't support my iPad.
The one thing they could have done for me is to allow location services to be toggled from the control center. But nope, that's not part of the available toggles that can be customized. Figures, since Apple wants that to stay on 24x7.
Sigh.
It started as another impulse buy of mine. Shocker.
While browsing eBay I spotted a new Google Cr-48 Chromebook. I snagged it for a decent price and had it a day or so later (the seller lives in Charleston, SC). Actually, I got it right before I left for New Jersey to participate in my college roommate's wedding.
The Google Cr-48 is a prototype piece of hardware running Chrome OS, a specialized distribution of GNU/Linux that runs only one application: Google Chrome. It was shipped out to 60,000 beta testers (at no cost) starting in December of 2010 and ending in March of 2011.
No, I didn't get one. And, at the time, after trying a few of Hexxeh's builds Chromium OS in VMware, I was glad I didn't - the OS seemed like a pile of garbage. My opinion has changed slightly, so read on.
After the Cr-48s had run their course, two new Chromebooks surfaced in the summer of 2011, boasting almost idential specifications to the Cr-48 except for different processor models (Atom N570 vs. Atom N455 in the Cr-48).
The Cr-48 that I obtained is apparently one of two models that beta testers received. Mine is labeled "IEC MARIO FISH 2330" and apparnetly there's another one out there labeled "IEC MARIO PONY 6101" (see this page for more details). It seems that they're idential, for all intents and purposes.
The hardware itself is fairly small and light, but huge and bulky compared to the MacBook Air. It's got a 12.1" screen (1280 by 800 pixels), 2GiB SSD, 802.11abgn Wi-Fi, webcam (I haven't tried this), and SD card slot. There's a USB port, too, but I've heard only HID-related and mass storage devices work correctly. The battery is fairly large, but thin, and sometimes feels like it doesn't sit very securely when installed. I suspect this is the result of corners being cut in the manufacturing or design process, since the laptop was originally intended for testing and not meant to be sold.
The keyboard has no F-keys and the would-be caps-lock key is a "search" button that opens a new tab. An oversized Alt key takes the place of a Windows key. There's no trackpoint-like device, just a touchpad that supports multi-touch, which seems to be coming out of the case, slightly. Again, this is probably due to corners cut in the manufacturing process.
The case itself has a soft rubbery feel and unfortunately visibly shows fingerprints and other grease marks, which sucks for those of us who suffer from OCD. That being said, one of the great things about the Cr-48's case is that it's completely free of branding. In fact, nobody really knows (with certainty) who manufactured the Cr-48s for Google. Anyway, the case looks like it might be a black MacBook at first glance.. but the white Apple logo on the screen is notably absent. I've seen one or two double-takes by people passing me by while hanging out at Panera Bread, and one person struck up a conversation with me about it. I dislike excessive branding, so this makes the Cr-48 a little bit more fun.
The Cr-48 also has another little hidden gem: a Qualcomm EvDO (rev. A) modem that operates on Verizon Wireless's network. Upon activation, there's two years worth of free data (up to 100MiB per month) included with the Cr-48. Data over 100MiB is charged to a credit card.
Oh, also, the battery lasts around a solid eight (8) hours with Wi-Fi enabled. The Atom processor's clock frequency is throttled by usage with cpufreq's "ondemand" scheduler.
Chrome OS is a pretty lean Linux distribution. No boot messages, no windows, just a logon screen and the Google Chrome browser.
The first boot presents the user with a list of languages, connectivity options (I chose Wi-Fi initially), and sign-on options (Google accounts only). Chrome OS then updates itself and reboots. I'll talk about the Google Chrome browser experience later, but other than items on the logon screen (language, connectivity options), all configuration and operation is done through browser tabs. This results in configuration feeling a little bit laggy, for some reason.
The Wi-Fi configuration is interesting, since it allows networks to be defined and saved on a per-user basis. This means that I can define a network, save the PSK (or whatever) for it, and only have the configuration accessible when my user is logged into Chrome OS. This doesn't really help me, but I suppose it can can be appropriate for some situations. The one weird thing about the network configuration is that proxy server settings must be done on a per-connection basis. I always run my browsing through a proxy (accessed via a VPN or SSH tunnel), so this is a little odd.
In reality, Chrome OS doesn't completely force the user to use a web browser for everything, a limited command-line environment (crosh) can be invoked by pressing Ctrl+Alt+t. Switching between Chrome browser windows (add more by hitting Ctrl+n, duh) is done with Alt+Tab, just like Windows. In fact, the whole thing runs on X11 but has a customized window manager that forces all applications to run in full-screen. Anyway, crosh lets one perform some diagnostics (traceroute, PING, etc.) and invoke an SSH client. The SSH client is troublesome because the terminal that crosh is started in (urxvt) somehow doesn't support UTF-8 properly, possibly due to the font selection. It's also annoying when connectivity drops, as there's no way to kill the SSH session (enter-~-. does not work).
Surprisingly, things like Netflix are supported due to Trusted Computing and Chrome OS's link with the built-in TPM. Basically, this gives content providers an assurance that their media won't be copied, stolen, or otherwise "hijacked" from users. If the Chrome OS bootup process is altered, I suspect the TPM will raise and error and prevent DRM-ish things from working.
In fact, speaking of preventing DRM-ish things from working.. there's a hidden developer button in the battery compartment that enables the "shell" command in crosh. I flipped this switch and it wiped all information on the Cr-48 and disabled the TPM (boot verification). I now have to hit Ctrl+d to bypass the frowny-face screen, but now I have access to the shell from crosh, and mostly everything works the same way. I say mostly everything.. because Netflix and other applications and pages that rely on the TPM won't work. No big deal, for me.
I've put some information I got from the shell here. One thing I just noticed while looking at the mount(8) output is that the stateful partition on the SSD is encrypted. I guess this is to prevent someone stealing the laptop, pulling the SSD out of it, and mounting it on another machine.
One nice thing about the developer switch is that Chrome synchronization with Google can be completely disabled. I don't care to synchronize things with Google, I'm weird like that, but unfortunately under normal operation you can't actually disable this (you can disable all but one category to synchronize, which is stupid).
Another nice thing about the developer switch is I can fire up an SSH tunnel from the shell (ssh -L etc..) and get access to a proxy server of mine, so I don't have to surf the Internet at coffee shops in the clear. I noticed OpenVPN binaries are installed, too, but I haven't bothered to setup anything to use it.
I've used Google Chrome before obtaining the Cr-48, but never liked it enough to switch from Iceweasel (a non-branded Firefox). I'm getting used to it a bit more on the Cr-48, since I don't really have a choice of browsers, but some things still bug me a bit.
Instead of using some bookmark synchronization tool or service, I have a personal "start" page of mine that lists all my bookmarks and sorts them by use. It's backed by a MySQL database, and I set this as my home page on all of my systems. I rely on Firefox's (and previously, Epiphany's) type-ahead find feature so I don't have to move my hand to the mouse in order to select a link. If I want to load a link, I hit Ctrl+t, type a unique subset of the link (shdot - Slashdot, for example) and it's logged to MySQL and loaded in my browser. Nice and fast.
Unfortunately, Google Chrome doesn't support the two features that allow me to take advantage of this: loading the home page for each new tab and type-ahead find. What's even worse is that they won't even add the type-ahead find as an option (see here). I've found two extensions that emulate this behavior:
Unfortunately, the Type-ahead-find extension is a little laggy, but it's better than nothing.
It's possible to download and install applications in Google Chrome using the Chrome Web Store. However, compared to the App Store in iOS or Mac OS X, most of the applications aren't really downloaded or installed, links for them are just added to the New Tab Page. Some applications seem to be able to request offline storage, like the Amazon Cloud Reader that allows the reading of Kindle books.
Although probably just limited by the Cr-48's CPU, 720p (or higher) Flash Video on YouTube barely plays. HTML5-based video runs fine, though (can we kill Flash now, please?).
Although I had severe reservations about a browser-only laptop, the Cr-48 seems to have softened my opinion of Chrome OS quite a bit. The funny thing is I'd probably recommend a Chromebook for my grandmother over any Apple product, at this point.
For techie or hacker-types, it's still a bit rough around the edges, but does show promise.
Well, it's been a little bit since I've blogged anything. Sorry about that. Let's see if I can hit the high points of the last month or so.
World IPv6 Day is approaching. Yep, by approaching I mean it's next week! If you don't know anything about it, click on the link. If you're too lazy to do that, go have some sugar. Basically, World IPv6 Day is when lots of high-profile sites will become dual-stack as a widespread test flight of the protocol. It'll only last for 24 hours, and most of the sites will remove the AAAAs at the conclusion of the test flight. It's scheduled on Wednesday, June 8th from 00:00 UTC to 00:00 UTC on June 9th.
(just for the record, prolixium.com has had an AAAA record for about eight years, at this point)
When taking breaks from studying for the JNCIP-SEC exam, I've gone back to my service provider lab, and implemented some RSVP-TE and interprovider VPNs. Strangely enough, the Juniper Olive makes a great MPLS P router, if you keep Junos below 8.5. I used a Juniper SRX210, Dynamips'ed Cisco 7200 running 12.4(15)T5, and a bunch of virtual machines running Debian GNU/Linux. Here's what it looks like:
Essentially, zat's fxp4.0 can talk to martini's Untrust interface via an MPLS L2 VPN established between ori and asgard. The L3 MTU is a little low (1426), but it works. Also, I started playing with MikroTik's RouterOS, too. It seems like a fully-featured operating system (erm, lacks IS-IS, but is close enough) for low-end CPE or MPLS LERs.
In other news, I just passed the JNCIP-SEC, today. It was a bit harder than I had expected, but I still emerged victorious. For some reason Prometric made me turn all my pockets inside-out (yes, this included my back pockets) before starting the exam. I was wondering if there was going to be a pat down, too. Crazy. Now, I suppose I should register for the JNCIE-SEC, right? I may start studying for the JUCIP-SP instead, since that will serve to recertify my JNCIE-M that expires next year (actually, I think it converts the JNCIE-M to JNCIE-SP). We'll see.
I picked up Anjunabeats Worldwide 03 and Paul van Dyk's Vonyc Sessions 2010, recently. Both compliations are quite epic, and the following tracks are my favorites, so far:
On another topic, I was over a friend's house on Memorial Day, earlier this week. He's got one of the newer 240Hz Samsung LED TVs with that hideous motion interpolation feature (in the form of Auto Motion Plus). I sat through a few minutes of Star Trek Generations, which I've seen over a dozen times, before deciding to see if there was a way of disabling it in the settings. There is, and it looks much better when disabled. I don't get the appeal.. it just makes everything look like a behind-the-scenes version of the fiim. Most Engadget HD readers agree with me.
My once happy Windows Media Center setup (on isis) stopped working, the other day. Apparently one of those lovely Microsoft updates to Windows 7 started causing WMC to die after a minute or two of usage with the dreaded nvlddmkm stopped responding and has recovered message. I couldn't grab a screenshot fast enough, but it looks something like this:
My first stab at fixing the problem was to uninstall the latest batch of Windows updates, which for me were:
It worked until I upgraded the hard disk in the machine, then Windows did some driver fussing and I started receiving the nvlddmkm errors once again. My latest solution is to uninstall all Microsoft updates (excluding security updates, those are nice to keep) including service pack 1. We'll see how well that works out. I'm still using version 183 of the nVidia drivers, since they allow me to use the VGA (ie, non-digital) output for premium channels that are protected by DRM. Newer revisions of the driver require DVI or HDMI output, and an HDCP-compliant monitor, which my 24" Dell isn't. Anyway, upgrading the driver didn't help fixing the original problem, so I'm not missing much.
It's been pretty hot in Charlotte for the last week or two. I'm talking 95°F and hotter for days on end. It seems to be higher than normal for this time of the year.
I think that's about it. I'll try to keep this more updated from now on, but no guarantees!
If you're from Charlotte, you know that the south loop of I-485 causes daily delays and traffic, due to its low lane count.
Well, it's even worse when it's closed.
My normal commute consists of exiting Ballantyne via Lancaster, a short trip on 51, and then I-485 for most of the rest of the trip. Today, knowing that I-485 is closed, I try to exit my development, and are greeted by a parking lot:
All of the exits out of Ballantyne are either blocked off or just a parking lot. So, I drove south, thinking I would be able to get on 160 to I-77 and head north. Along the way, I noted that Johnston Rd was backed-up pretty far:
Unfortunately, I had to drive much farther south than I had expected. The total distance was 50 miles and took a little less than an hour and a half:
Surprisingly, I heard stories of folks sitting in traffic for two and three hours, and having to turn around and go home! So, my commute wasn't too bad. Very scenic, too.
Alright.. pick yourself off the floor. YES, IPv6 and NAT+PAT (many folks call it just NAT or NAPT but I'm calling it NAT+PAT to be as precise as possible) are in the title. Keep reading, don't be frightened.
NAT+PAT is a hack introduced in the mid-1990s to help combat IPv4 address exhaustion. It became wildly popular in residences and large enterprises that needed to attach multiple computers to an Internet connection with only a single public (PA) IPv4 address. Unfortunately it breaks end-to-end connectivity, which impacts many protocols, and provides some network administrators with a false sense of security. Bottom line is that it sucks, and it needs to go away.
Enter IPv6, the new protocol with an almost limitless address space. NAT+PAT won't be needed anymore with IPv6, they'll be a thing of the past! Well, almost. One accepted scenario where NAT+PAT will still be used is load balancing. Although, some may not even view load balancing as actual NAT+PAT, but a simple TCP proxy. Call it what you will, but the real servers in a load balanced environment (assuming no DSR) won't typically see the source address of the client hitting the VIP. They'll see requests coming from address(es) on the load balancer itself.
So, other than load balancing, IPv6 NAT+PAT isn't needed, right? Well, read on, because I'll present a somewhat common IPv6 dual-stack deployment that might be able to benefit from sugh a beast.
Enter a company called Foo and Associates. This company doesn't exist, and I'm making all this stuff up. However, the design may look strangely similar to other networks out there. Here's a diagram to start you off:
The above diagram shows Foo and Associates' network, AS64499. They've got chunks of IPv4 and IPv6 PI space and use 10.10/16 internally. There's two data centers and a few branch offices with private (MPLS, leased lines, whatever) WAN connectivity back to the DCs. The DCs have some users and servers, and the branch offices just have users. Right now, the branch offices access the IPv4 Internet through either of the two DCs, and get translated (NAT+PAT) to the external address(es) of the Internet firewalls depicted in site 1 and site 2.
There is a "dirty" segment that the firewalls live on as well as the Internet routers, which maintain connections to a few transit providers. The two Internet routers have a private WAN link between them to be used for redundancy in case the transit providers fail at one particular DC. The following diagram shows both the IPv4 and IPv6 advertisements:
Now let's talk about how IPv4 works.
The DC servers just talk to the Internet without NAT or PAT or any translation. The Internet routers statically route the appropriate subnets to the DC firewalls, and everything works properly. The IPv4 advertisements are tweaked (as you can see in the diagram) so each /23 worth of DC server space is routed symmetrically in a hot-potato fashion.
Internet access from the RFC 1918'ed campus networks goes through the Internet firewalls at each of the DCs. An IPv4 default route is followed based on WAN link costs, and traffic is translated via NAT+PAT out the Internet firewalls. If one DC dies, the branch offices that are sending Internet traffic to it just move over to the Internet firewall at the other DC. Here's a diagram of the outbound IPv4 Internet access flow:
And here's one showing the return traffic:
Let's also say some of the WAN links are a bit more latent than the others, either due to fiber routes or the geographic location of the sites of Foo and Associates. The internal routing always takes the path with the lowest latency to determine the best way to the Internet. Sure, it could be EIGRP or it could be IS-IS with some mechanism to tune link costs based on latency. The details aren't relly important, here.
Now, let's talk about what happens when Foo and Associates deploys IPv6.
After getting a /40 assignment from their local RIR, Foo and Associates deploys IPv6 right on top of their current infrastructure, essentially dual-stacking everything. The first diagram shows all the IPv6 addressing, so you might want to look at that again.
However, instead of deaggregating and sending longer prefixes to the DFZ, they Go Greenࡊ and only announce their /40 equally out of each data center. The DC servers don't have a problem with this, as there are IPv6 static routes (and advertisements in IBGP, just like there were for the IPv4 specifics in the previous section) pointing from the Internet routers at each DC to the /48s of public space. Egress traffic from the servers will exit locally, and ingress traffic can be received either locally or from the other DC, where it will be sent over the WAN link toward the correct site. The DC firewall sees both traffic flows, and everything works as expected.
What doesn't work correctly is Internet access from the branch offices. Since any part of the company could access the Internet via either of the Internet firewalls, the Internet routers have the whole /40 routed to the Internet firewalls for return traffic. Now, keep in mind that Foo and Associates has stateful firewall policies allowing internally-initiated outbound Internet traffic, but not Internet-initiated inbound traffic. Here's the outbound IPv6 Internet access:
And illustrating the specific case where things break, here's the return traffic:
Now you see the problem. If Google decided to send traffic back to Foo and Associates via transit provider B, it would get lost. The Internet firewall at site 2 doesn't have a record of the outgoing connection (SYN packet to [2001:4860:8008::68]:80) so it denies it thinking it's invalid traffic. Meanwhile, the Internet firewall at site 1 never sees any inbound traffic to the session it opened to [2001:4860:8008::68]:80. Eventually, the user's browser at site 3 times-out and falls back to IPv4.
There are a few potential fixes to the above problem. Unfortunatly, every one of them has some drawback. Let's go over them individually.
1: Deaggregate
Foo and Associates could deaggregate and advertise a whole bunch of /48s in addition to (or in place of) its /40. The /48s of the sites closest to site 1 would be advertised out of Internet router A and the /48s of the sites closes to site 2 would be advertised out of Internet router B. This would allow the firewalls at each DC to see both the outbound and inbound traffic flow. Sounds like it might work!
However, even if the ISPs accepted the longer prefixes (and their upstreams did as well), what if the latencies of the WAN links change one day, and sites that normally have their best path out of site 1 flip over to site 2? Latencies of leased lines might not move around too much, but latencies of MPLS-provisioned L2VPNs might fluctuate if the provider is building out a new ring or making network changes. So, again some sites might encounter the original problem and end up with asymmetric flows getting nuked by the firewalls.
2: Move the firewalls
An expensive way of solving this problem is to remove the Internet firewalls in the DCs and move them closer to the users. This means that the campus networks at each of the DCs would have their own firewalls, and each of the branch offices would have theirs, as well. Since there's only one way in and out from each of the campus networks, the problem goes away.
Unfortunately, even if firewalls grew on trees (or were free), there are some security implications with this design. Essentially, Foo and Associates' private WAN becomes a public one. Rogue Internet traffic can make its way into the WAN, even if it's blocked before it gets to the users. A DDoS that might normally not cause the Internet transit links to blink could consume one of the WAN links easily, disrupting operations. This option isn't too bad, but it's not going to fly if Foo and Associates happens to be a financial company. Although, Foo and Associates could just ditch the WAN and move to Internet-based VPNs, but then QoS goes out the window for any VoIP-related things, MTU becomes an issue, and bleh.
3: Link the firewalls
If the Internet firewalls in each data center support high availablity and state table sharing, it might be possible to link them together. Some vendors say that this type of setup will work up to 100 ms but it typically needs two links, jumbo (>= 9100 bytes) frame support, and no VLAN tag manipulation. So, Foo and Associates could buy two dedicated MPLS L2VPNs with jumbo frame support and a latency SLA that's below 100 ms. This way, the firewalls could maintain a common state table and know about the outgoing state even if it's been built through a different firewall.
This might work, actually. But is it a good idea? Maybe, maybe not. Session set-up time may be longer if the session table has to be updated synchronously. What happens if the provider breaks their SLA and the latency exceeds 100 ms? Session table disaster is the probable outcome.
4: Only use one site for IPv6 Internet
Another simple yet unattractive option is to tweak routing so only one DC is used for IPv6 Internet access. If site 1 was chosen, the /40 advertisement out of site 2 would be prepended, and the BGP local preference attribute would be used to influence the exit path. If site 1 drops off the map, site 2 could still be used as backup (since there would be no other routing announcements to choose from). Note that this wouldn't affect the DC servers.
The problem with this plan is obvious: latency. Sites that have the shortest path to site 2 for Internet access would go through site 1, instead. If site 4 is on the west coast and site 1 is on the east coast of the United States, this could get annoying. What if site 4 was in San Francisco and site 1 was in New York? Should the packets for UCLA's website over IPv6 really have to cross the country and back? Yeesh.
5: Forget security
The title says it all. Throw out those Internet firewalls. Let's go back to the old days when there weren't any firewalls. Seriously, if Foo and Associates is a college or university, this may be the way to go. No firewalls, no session tracking, and no problems!
Although this may be a bit unorthodox in this day and age, a compromise might be to turn of SYN packet checking on the firewalls and allow traffic on ports above 1024 to generate sessions even if the 3-way handshake was never observed. Or, replace the firewalls with routers that do stateless filtering to achieve the same goal.
6: IPv6 NAT+PAT
Here it is, folks. Add IPv6 NAT+PAT to the Internet access policy on the Internet firewalls in both DCs, and you're set. IPv6 Internet access is then optimized for latency (well, as well as it was for IPv4) and the problem with return traffic disappears. Here's a diagram:
And the return path:
Problems.. there are tons of them. This breaks end-to-end connectivity, AGAIN. It feels like the mid-1990s all over again. IPv6 NAT+PAT isn't really implemented in many devices, yet, but it's implemented in OpenBSD's PF. The simplicity of this solution is hard to deny, even with the problems (philosophical and other) it presents.
And there you have it. Are there solutions 7, 8, and 9? I sure hope so. Feedback, please. I'd love to hear it.
So, I had an opportunity to attend NANOG47. I was actually one of five of the employees from my company who were there, which is a lot. I only ended up meeting up with two of them, though. People were pretty scattered most of the time. Actually, if it weren't from the newcomers breakfast where we all stood up and said who we were and our employer, I would have missed them entirely.
NANOG47 was held in Dearborn, Michigan at the Hyatt Regency Dearborn hotel. The hotel is within walking distance from the Ford worldwide headquarters:
The weather wasn't all that bad, but I wasn't outside too much. However, inside the ballrooms, where most of the presentations were, it felt like they had the air conditioning on, or something. It had to be 65-68°F. I wore my jacket the whole time when I was outside my hotel room.
Just like all NANOG meetings, there was a wireless network with a couple ESSIDs on various frequencies providing a range of services. The nanog-arin-a (ARIN too, because the ARIN XXIV conference was back-to-back with NANOG47) ESSID provided IPv4 and IPv6 services via 802.11a, the nanog-arin ESSID via 802.11g, and the nanog-arin-v6only ESSID just provided IPv6.
I tried out the IPv6-only ESSID at first. I could hit all prolixium.com services (web, DNS, mail, XMPP), which really wasn't any surprise. Google, Cogent, Hurricane Electric, FreeBSD, ARIN, NANOG, etc. all worked. I was a little surprised that the command-line whois utility on Linux worked just fine, too, although I only queries I tried were for ARIN IPv6 addresses.
So, I used the other two ESSIDs the rest of the conference. My wlan0 interface looked like this most of the time:
wlan0 Link encap:Ethernet HWaddr 00:13:02:17:89:2a
inet addr:192.35.166.229 Bcast:192.35.167.255 Mask:255.255.252.0
inet6 addr: 2620:0:ce0:1:213:2ff:fe17:892a/64 Scope:Global
inet6 addr: fe80::213:2ff:fe17:892a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:259 errors:0 dropped:0 overruns:0 frame:0
TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:28081 (27.4 KiB) TX bytes:9265 (9.0 KiB)
The mentioned ESSIDs actually made their way up to the 10th floor of the hotel via extensions of the VLANs or WDS. I had to pay for Internet access the first night (ugh, T-Mobile) since I arrived early, but the rest of the week I was set. That being said, the connectivity up on the 10th floor was pretty lossy most of the time.
I believe the NANOG connectivity from the hotel was provided by a 50Mbit/sec pipe by AT&T to Ann Arbor, and then from there via the Merit Network & Internet2 + peers. IPv4 traceroute looked like this:
% traceroute -q1 dax.prolixium.com. traceroute to dax.prolixium.com. (69.9.189.182), 30 hops max, 60 byte packets 1 rtr01.nanog.merit.net (192.35.164.1) 4.099 ms 2 198.108.90.53 (198.108.90.53) 8.717 ms 3 xe-0-0-0x76.wsu5.mich.net (198.108.23.9) 14.567 ms 4 198.109.37.22 (198.109.37.22) 23.015 ms 5 xe-2-0-0.0.rtr.newy32aoa.net.internet2.edu (64.57.28.74) 29.150 ms 6 198.32.118.47 (198.32.118.47) 28.727 ms 7 0.te6-1.tsr1.ewr1.us.voxel.net (208.122.20.129) 29.310 ms 8 0.te1-49.dsr1.lga6.us.voxel.net (208.122.44.122) 29.806 ms 9 0.ge0-1.esr2.b3.lga6.us.voxel.net (208.122.5.42) 39.524 ms 10 dax.prolixium.com (69.9.189.182) 33.308 ms
And IPv6 like this:
% traceroute6 -q1 dax.prolixium.com. traceroute to dax.prolixium.com. (2001:470:8ad6:4::a), 30 hops max, 80 byte packets 1 2620:0:ce0:1::1 (2620:0:ce0:1::1) 2.805 ms 2 2001:48a8:7fff:3::1 (2001:48a8:7fff:3::1) 7.135 ms 3 2001:48a8:48ff:ff01::5 (2001:48a8:48ff:ff01::5) 15.663 ms 4 10gigabitethernet4-1.core1.chi1.he.net (2001:504:0:4::6939:1) 20.172 ms 5 10gigabitethernet2-4.core1.nyc4.he.net (2001:470:0:4e::2) 40.099 ms 6 1g-bge0.tserv4.nyc4.ipv6.he.net (2001:470:0:5d::2) 42.134 ms 7 dax.prolixium.com (2001:470:8ad6:4::a) 43.791 ms
Since everyone had public (and unfiltered) IPv4/IPv6 addresses on their laptops, it was funny to see all the Symantec & McAfee pop-ups on people's screens for attacks coming from the Internet. I feel sorry for the folks who will be bringing malware back to their corporate networks. Should have used a firewall or HIDS (or GNU/Linux)! There were also LOTS of MacBooks and iPhones on the network. I took a small sampling of the mDNS messages that were clogging the airwaves here (warning, large text file). Is mDNS getting worse than NetBIOS broadcasts? At least my laptop wasn't one of the ones announcing itself to the network saying HACK ME, PLEASE!
Anyway, onto the interesting stuff. Most of the talks and presentations were interesting (agenda with all the presentations is here). If I had to sum them all up in a couple lines, it would be something like this:
Some of the presentations were fairly interesting. I'll go over some of the highlights.
Tutorial: How to Accurately Interpret Traceroute Results: This was excellent. Basically Richard Steenbergen went over possible reasons for latency, cheat sheet of CLLI codes and router naming schemes, and impact of MPLS as it relates to traceroutes. I'd suggest anyone who is in an operational role read this.
Scripting on Routers: (first presentation, second presentation): I've actually started to write some op scripts on JUNOS, recently, and this stuff is very powerful. However, and some people pointed this out after the talk, most companies won't let you do this for fear of a typo taking out all routers at once. I think we as a community need to just bite the bullet and get over this fear - networks aren't getting smaller, and if we have to configure each router by hand, operators days are going to get very long.
Virtual Aggregation: This is a protocol designed to decrease the FIB sizes on smaller routers in the enterprise, as the DFZ grows larger and larger. I don't necessarily think it's a great idea, mostly because it's quite complex and can put a large burden on the puny CPUs that oversee the routing protocols in most routers. As I said earlier, I don't think there's really an easy (or good) way of aggregating prefixes you don't own.
BGP#: A System for Dynamic Route Control in Data Centers: Sorry, I think this is an awful idea, too, but well presented. Chao-Chih described an extension to BGP (BGP#) that would essentially allow applications (well, the "MultiSpeaker" peers) to control traffic flow in a data center via an API. Half of the presentation sounded like load-balancing, while the other half sounded like real routing. Either way, I think it's a bad idea for an external party to influence routing decisions and traffic flow. Let's just stick with health checks on load-balancers, please? It's quite possible that I missed the point, too :-)
IEEE P802.3ba 40 GbE and 100 GbE Standards Update: Sounds like we're almost there with really fast Ethernet (~2010). It's too bad that the distance for the copper PHYs was decreased to 7 meters from 10 meters. I guess it just didn't hold up. The QSFP transceiver seems like a natural extension of the SFPs we use today, and the CFP modules look a little too large for typical use. The new MPO fiber plug looks interesting, but I'll have to see it for myself.
RSTP to MST Spanning-Tree Migration in a Live Datacenter: Interesting. I've never really thought about using MST vs RSTP, but with all the VLANs and flexibility applications and servers need, it may be something to look into. A ~40 second outage window for the core wasn't too bad, although in my organization I suspect it wouldn't sit too well.
The Future of Internet Exchange Points: I don't know if I just interpreted this oddly, but it seemed like the whole gist of this presentation was: L2 sucks, L3/MPLS is good. In general, I think that's the way networks (campus, DC, etc.) are going these days, due to the security and reliability problems with L2 environments (spanning tree, etc.). However, it's suggested that exchanges just build lots and lots of MPLS L2VPNs (pseudowires) between peers. Not sure about this - it's a little wasteful of IPv4 space, and it requires more work on the IX'es side. Maybe not, though?
BGPbotz: Cool idea. I added this guy to my XMPP list and sent it a few commands:
(02:02:19 PM) prox@prolixium.com/Pidgin: sho ip bgp 208.122.0.0
(02:02:20 PM) bgpbotz@jabber.research.merit.edu: show ip bgp 208.122.0.0
BGP routing table entry for 208.122.0.0/20
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
11537 29791
198.108.93.41 from 198.108.63.41 (198.108.63.41)
Origin IGP, metric 279, localpref 110, valid, internal, best
Community: 237:1 237:1300 237:11537 1299:2609 1299:5769 11537:25200 29791:100
Extended Community: RT:11537:1
Last update: Sun Oct 18 02:07:54 2009
(02:02:25 PM) prox@prolixium.com/Pidgin: ping 69.9.189.182
(02:02:27 PM) bgpbotz@jabber.research.merit.edu: ping 69.9.189.182
PING 69.9.189.182 (69.9.189.182) 56(84) bytes of data.
64 bytes from 69.9.189.182: icmp_seq=1 ttl=55 time=20.9 ms
64 bytes from 69.9.189.182: icmp_seq=2 ttl=55 time=19.8 ms
64 bytes from 69.9.189.182: icmp_seq=3 ttl=55 time=19.7 ms
--- 69.9.189.182 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 19.760/20.158/20.907/0.554 ms
Although, I don't really have a problem with opening up a CLI and starting a telnet session to route-server.nlayer.net and others.
National Broadband Plan: The FCC guy was here. He gave a presentation about traffic engineering and national broadband. I just have a really sick feeling about this whole thing. I don't think the government should be involved in this, at all. I guess I don't have anything interesting to say about it.
So, the rest of the presentations either revolved around IPv6 or DNSSEC, or I just didn't find them too interesting. The IPv6 presentations were interesting, but not all that helpful to me. Most of them talked about deploying IPv6 in the core or the backbone, and that's the easy part! Nobody wanted to talk about IPv6 in the enterprise, on the LAN, or to backoffice applications. I guess take the easy road!
I also attended the peering track, which was basically 90 minutes where IX operators could give updates on their operations and plug new services (or more high-capacity ports). It also allowed smaller ISPs (and not-so-small) to give a small bio about their operations and ask others to peer with them. The highlight of this session was Hurricane Electric baking a cake for Cogent (see this message for history) to get them to peer with them. I saw the cake myself, it was real! Here's a photo:
On Wednesday evening we had a pizza & beer session up in the Rotunda of the Hyatt. On the 16th floor, the rotating (slowly) ballroom provided quite a view. I tried to take a photo, but it came out blurry:
All in all, a good conference. I took some other miscellaneous photos, and am posting them here.
I hate ATI. I hate them more, now.
Over the last year or two the driver support for the "Mobility Radeon 9600 M10" in my IBM T42 has steadily been getting worse.
First, there's some problem with 2D acceleration, so things start drawing a little slower. 3D will still work, so will XVideo. I figured this would be fixed, but I guess not.
Then, some driver bug is introduced recently that doesn't allow the fglrx kernel module to work (see previous blog post). This prevents XVideo and 3D acceleration from working at all. No chance at all to play videos fullscreen anymore without XVideo, as everything will have to be done in software.
Now, nothing works at all. X won't start:
(II) Primary Device is: PCI 01@00:00:0 (WW) Falling back to old probe method for fglrx (II) ATI Proprietary Linux Driver Version Identifier:8.65.4 (II) ATI Proprietary Linux Driver Release Identifier: 8.65 (II) ATI Proprietary Linux Driver Build Date: Aug 13 2009 21:15:30 (II) Loading PCS database from /etc/ati/amdpcsdb (EE) No devices detected.
And aticonfig hates me:
eclipse:/etc/X11# aticonfig --ovt Xv --initial -i /etc/X11/xorg.conf aticonfig: No supported adapters detected
I don't know why I still keep this laptop. I use my Eee PC almost exclusively when I'm mobile, now. The fan still has some problems, too (even after replacing it once), so sometimes it won't boot up due to a fan error.
Thinking of defenestration!
For better or worse, I use Debian as my GNU/Linux distribution of choice. More specifically, I use the testing distribution. Typically, this distribution contains a steady stream of new packages and versions that will most likely make it into the next release. Occasionally some broken packages make their way into the distribution, but not too often.
Unfortunately, bugs in the testing distribution seem to be adding up, at least for me. Here's a couple:
Apparently the snd-pcsp module that's supposed to provide a method to output sound to the PC speaker was renamed to snd_pcsp, in the latest kernel release (2.6.30-1-686, at least). The ALSA package normally blacklists the snd-pcsp module so it won't end up being the default output device. Unfortunately, it hasn't been updated to the new naming scheme for the module, so the PC speaker might become the default output device.
This sucks for a couple reasons. First, PC speaker output sucks - you almost never want to use this. Second, removing the snd_pcsp module doesn't help, even if you restart or reset /etc/init.d/alsa-utils. Annoying.
Luckily, there's an easy solution. Just blacklist the module yourself, and reboot:
# echo "blacklist snd_pcsp" >> /etc/modprobe.d/blacklist.conf # shutdown -r now
Upon reboot, the system should be back to normal. There's probably a way of doing this w/out a reboot, but I couldn't figure it out. Removing all the relevant modules and restarting the ALSA subsystem didn't do the trick.
This is documented in Debian bug #522758.
We all know ATI video cards are terrible, and the drivers are almost as unstable as the San Andreas Fault. Now, it sems, the fglrx-modules-2.6.30-1-686 (2.6.30+9-6-1) won't load at all on my IBM T42, after upgrading to linux-image-2.6.30-1-686 (2.6.30-6):
[ 30.449441] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [ 30.449455] Disabling lock debugging due to kernel taint [ 30.543780] [fglrx] Maximum main memory to use for locked dma buffers: 1898 MBytes. [ 30.544230] [fglrx:drm_alloc] *ERROR* [driver] Allocating 0 bytes [ 30.544241] [fglrx:firegl_init_device_list] *ERROR* Out of memory when allocating device heads [ 30.544250] [fglrx:firegl_init_module] *ERROR* firegl_init_devices failed
No workaround.
Yeah, allocating 0 bytes probably won't work. Fail. This one's documented in Debian bug #538431.
I hate wires, so I use Bluetooth headphones to listen to music. The bluez-audio (3.36-3) package has always worked for me. My .asoundrc was nice and simple:
% cat .asoundrc
pcm.bluetooth {
type bluetooth
device 00:0A:C9:24:16:98 # Backbeat 9xx
}
Unfortunately, when Debian upgraded all the bluez stuff to 4.42-2, they broke it. Actually, they deprecated the bluez-audio package in favor of the bluez-alsa package, for some reason (I guess the name is better).
Now, MPlayer (or anything else) spits out errors and doesn't work anymore:
alsa-lib: pcm_bluetooth.c:1607:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
Now, there are a couple profiles that can be used in the .asoundrc file for Bluetooth audio: audo, hifi, and voice. voice is used for, well, voice - talking on a cellphone or similar. hifi is the default, since if provides stereo Hi-Fi audio via A2DP. auto selects whatever's best for the device, in my case it selects hifi. But, the hifi profile doesn't work anymore, only the voice profile does (and it sounds terrible).
No workaround.
This is documented in Debian bug #532098.
If any of these things are important to you, don't upgrade the affected packages! At least, not yet.
Displaying page 1 of 5 of 34 results
     |
This HTML for this page was generated in 0.026 seconds. |