|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
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.
It's no secret that I have a minor form of OCD, and I wash my hands way too much during the day. During the winter and when I swim, my hands dry out to the point where they get really rough and occasionally bleed. The only hand cream that seems to really do the trick is Neutrogena Fast Absorbing Hand Cream.
I was running low, recently, so I picked up 8x bottles from Amazon to last me the winter. Their new obnoxious packaging in the form of sticky tape annoyed the heck out of me, so I sent them a note:
Hi -
I recently received 8x bottles of Neutrogena Hand Cream (ASIN #B001E96OBU). Although the product's basic functionality (dispenses the correct type of lotion) works as expected, I am frustrated and disappointed with the packaging method that I can only guess is used to prevent accidental leakage of the lotion during transit.
The two orders (each order comes in a pack of 4) are individually wrapped in an easily-removed piece of plastic. However, each individual bottle has a piece of what looked to be a variant of Scotch tape covering the cap, preventing it from opening. This in itself appeared to be a minor nuisance, but turned into a serious complication as the tape ripped and almost disintegrated upon removal. To make matters worse, after spending several minutes removing the tape from the bottles, at least some piece of the glue from the tape remained on all bottles. The removal of this glue from the bottles necessitates the use of a 3rd party agent, such as Goo Gone, or type of degreaser. Without this additional work and effort, a good portion of each bottle (including the cap) is sticky to the touch, and looks visibly dirty.
Although this item performs its basic function as expected, this additional packaging damages each tube to the point where it is difficult, frustrating, and uncomfortable to use. I realize that some care must be taken to ensure that the bottles do not open in transit. However, this type of tape is obviously not the right solution. An alternate method such as rubber bands or small wire ties might be used, instead. These methods prevent any residue remaining on the product after removal.
If this hand creme were available at any other retail store in my area, I would not hesitate to purchase it there. As it stands right now, this will be my last purchase of this item and I will avoid using Amazon.com for any future purchases of similar products in the future, fearing that others may be taped in a similar method.
I hope this feedback is valuable to Amazon.com.
- Mark Kamichoff
Maybe they'll fix it. Until then, I take my business elsewhere.
I keep running into this annoying problem, and have finally found a decent workaround. Here's a little background:
Linux's IPv6 autoconf system runs when an interface is brought up & is marked as RUNNING. On wired (Ethernet) this usually means there is some sort of link on the interface. An IPv6 link-local address is assigned to the interface based on the EUI-64 for the interface, which in turn is based off the MAC address. The Linux kernel sends a couple of ICMPv6 router solicitation messages to ff02::2 (the link-local multicast address for all routers), waits for the reciept of a router advertisement message, then acts on the information provided. Usually the router advertisement message contains an IPv6 prefix (/64, in almost all cases), a lifetime, and some miscellaneous options. Linux takes the EUI-64 for the interface, appends it to the prefix it just received, and binds it to the interface. A default route (::/0) is also generated, having a gateway of the link-local address of the router that sent the advertisement message.
This works just fine most of the time. However, with some wireless networks and instances where the interface is brought up the first time when on the wrong (or nonexistant) network, problems can occur.
The biggest issue seems to be Linux's inability to re-send router solicitation messages when an interface is bounced, at regular intervals, or even on demand. Try this scenario:
Ok, that turned out to be a silly scenario, but you get the picture. We all too often see the message:
eth0: no IPv6 routers present
…when we plug into something that doesn't /yet/ have connectivity to the rest of the network, but will soon.
A better example, and the one that I get burned by all the time, revolves around wpa_supplicant and wireless interfaces. When I bring up the interface on my laptop, Debian runs wpa_supplicant for me. The link is immediately brought up and flagged as RUNNING, but wpa_supplicant hasn't finished authenticating, and sometimes takes 20-30 seconds, depending on the network. Unfortunately, the kernel gives up on the router solicitation messages before real connectivity is available.
To make matters worse, bouncing the interface doesn't always cause the kernel to resend the router solicitation messages. I have to rmmod the module, then insmod and start all over again.
Enter the ndisc6 tools package. ndisc6 is a collection of IPv6 diagnostic tools for Linux and *BSD, and includes rdisc6(8), a userland application that implements the router discovery process, and can tell the kernel to update its autoconfiguration state. It's available as part of the ndisc6 package (duh) on Debian/Ubuntu. Running it like this will refresh/assign the autoconfigured addresses and recreate the default route:
% sudo rdisc6 eth0 Soliciting ff02::2 (ff02::2) on eth0... Hop limit : 64 ( 0x40) Stateful address conf. : No Stateful other conf. : No Router preference : medium Router lifetime : 1800 (0x00000708) seconds Reachable time : unspecified (0x00000000) Retransmit time : unspecified (0x00000000) Prefix : 2001:db8:8ad6:5::/64 Valid time : 86400 (0x00015180) seconds Pref. time : 14400 (0x00003840) seconds Source link-layer address: 00:03:23:5F:4D:D9 from fe80::203:23ff:fe5f:4dd9
Yep, just like that. It's really not a fix for the problem, but it's a good workaround, since it doesn't involve bouncing interfaces or reloading modules.
The BSDs have rtsold, that supposedly runs as a daemon and manages scheduling of the router discovery process in userland. Perhaps Linux needs this, so router discovery can be triggered after certain events (wpa_supplicant succeeding).
I was in Los Angeles (it was cool there, I should have brought a jacket) for work this past week, so I setup a webcam to record a timelapse of my condo in my absence. Turns out that the only interesting thing was my plant:
(1 frame every 10 seconds, encoded at 20fps)
YouTube compressed the video a bit too much. View the original here (MP4, H.264).
Can't do this in bash:
(dax:22:02)% pwd /usr/local/www/apache22/www.prolixium.com (dax:22:02)% cd com net /usr/local/www/apache22/www.prolixium.net
Say I have tons of MP4 files. Some have a suffix of "(iTouch).mp4" but most don't. Here's how I list the ones without the iTouch:
% setopt extended_glob % ls *.mp4~*iTouch\).mp4 A Clockwork Orange.mp4 Babylon A.D..mp4 Get Smart.mp4
Maybe I want to remove all files with the "(iTouch).mp4" suffix to just ".mp4" without using Perl or mmv(1):
% autoload -U zmv % ls *.mp4 A Clockwork Orange (iTouch).mp4 Get Smart (iTouch).mp4 Babylon A.D. (iTouch).mp4 % zmv '*(iTouch)*' '$f:s/ (iTouch)//' % ls *.mp4 A Clockwork Orange.mp4 Babylon A.D..mp4 Get Smart.mp4
Just a few things that saved me some time, tonight.
This is strange, whenever I reset my Cisco 7960G IP phone from the telnet interface, when the phone comes back up it sends a steady stream of TCP ACK packets to my workstation:
12:31:38.380373 IP 10.3.5.104.23 > 10.3.5.107.47447: Flags [.], ack 1, win 1400, length 0 12:31:38.380385 IP 10.3.5.107.47447 > 10.3.5.104.23: Flags [R], seq 1654266114, win 0, length 0 12:31:38.400391 IP 10.3.5.104.23 > 10.3.5.107.47447: Flags [.], ack 1, win 1400, length 0 12:31:38.400400 IP 10.3.5.107.47447 > 10.3.5.104.23: Flags [R], seq 1654266114, win 0, length 0 12:31:38.420410 IP 10.3.5.104.23 > 10.3.5.107.47447: Flags [.], ack 1, win 1400, length 0 12:31:38.420422 IP 10.3.5.107.47447 > 10.3.5.104.23: Flags [R], seq 1654266114, win 0, length 0 12:31:38.440379 IP 10.3.5.104.23 > 10.3.5.107.47447: Flags [.], ack 1, win 1400, length 0 12:31:38.440393 IP 10.3.5.107.47447 > 10.3.5.104.23: Flags [R], seq 1654266114, win 0, length 0 12:31:38.460447 IP 10.3.5.104.23 > 10.3.5.107.47447: Flags [.], ack 1, win 1400, length 0 12:31:38.460460 IP 10.3.5.107.47447 > 10.3.5.104.23: Flags [R], seq 1654266114, win 0, length 0
(10.3.5.104 is the phone, and 10.3.5.107 is my workstation)
Resetting the phone by the buttons (hold down *, 6, and settings) breaks it out of this loop.
Weird.
Displaying page 22 of 121 of 965 results
     |
This HTML for this page was generated in 0.004 seconds. |