It was terribly overpriced, but I had to get it:

It's actually the U.S.S. Enterprise NCC-1701-D from a possible future, as seen in All Good Things:

In my humble opinion, the top three (3) trance hits of all time:

• Paul van Dyk - Nothing But You
• Above & Beyond - Good for Me (Above & Beyond club mix)
• Paul van Dyk - La Dolce Vita

Just thought I'd share that.

My desktop (destiny), passed 100 days of uptime, today.  Not too bad, considering it's running VMware Workstation, john, MythTV, and has undergone several Xorg upgrades.

20:36:51 up 100 days, 1:45, 17 users, load average: 1.08, 1.26, 1.24

Pales in comparison to a router we have at work, though:

8:26AM up 736 days, 7:37, 1 user, load averages: 0.06, 0.05, 0.01

My Lenovo T60 can't get past 20 days without it hard locking :-(

Mostly it's my fault, for not catching it sooner.  I printed 50 pages of a large PDF from Evince, and didn't realize it decided to play a joke on me, until it had finished:

There's a new firmware out for the Nokia E61i smartphone.

DO NOT UPGRADE UNLESS YOU HAVE TO!

I had a pretty horrible experience upgrading mine, the other day, mostly due to the crappy Windows software updater and PC suite I was forced to use.  First off, whenever I plugged in the phone, Windows would sit there for like 20 minutes finding different things, and installing drivers.  The software updater let me know it would wipe the phone during the update, so I installed the Nokia PC suite to back it up.  It wouldn't have been too bad, except both applications only seem to work 1/5 of the time.  Most of the time, the splash image will come up on the screen, and just hang (requires a log off or reboot).  After I did the upgrade, I had to format my MicroSD card since the phone would hang on the "Installing" message upon bootup.

I ended up only restoring my contacts from the backup, and redoing all the settings manually.  And, I really see no improvements.  Oh well, live and learn.

Quagga's ospf6d (OSPFv3 daemon) has been crashing on several of my boxes since the Debian 0.99.9-2 update:

2007/12/02 19:33:30 OSPF6: Assertion `orig->retrans_count >= 0' failed in file ospf6_flood.c, line 203, function ospf6_decrement_retrans_count 2007/12/02 19:33:30 OSPF6: Backtrace for 15 stack frames: 2007/12/02 19:33:30 OSPF6: [bt 0] /usr/lib/libzebra.so.0(zlog_backtrace+0x1f) [0xb7edcecb] 2007/12/02 19:33:30 OSPF6: [bt 1] /usr/lib/libzebra.so.0(_zlog_assert_failed+0x99) [0xb7edd028] 2007/12/02 19:33:30 OSPF6: [bt 2] /usr/lib/quagga/ospf6d(ospf6_decrement_retrans_count+0x51) [0x805e751] 2007/12/02 19:33:30 OSPF6: [bt 3] /usr/lib/quagga/ospf6d(ospf6_flood_clear_interface+0x5f) [0x805e7b5] 2007/12/02 19:33:30 OSPF6: [bt 4] /usr/lib/quagga/ospf6d(ospf6_flood_clear_area+0x22) [0x805e83e] 2007/12/02 19:33:30 OSPF6: [bt 5] /usr/lib/quagga/ospf6d(ospf6_flood_clear_process+0x42) [0x805e8c4] 2007/12/02 19:33:30 OSPF6: [bt 6] /usr/lib/quagga/ospf6d(ospf6_flood_clear+0x14) [0x805e925] 2007/12/02 19:33:30 OSPF6: [bt 7] /usr/lib/quagga/ospf6d(ospf6_install_lsa+0x88) [0x805f0d9] 2007/12/02 19:33:30 OSPF6: [bt 8] /usr/lib/quagga/ospf6d(ospf6_receive_lsa+0x388) [0x805f4d7] 2007/12/02 19:33:30 OSPF6: [bt 9] /usr/lib/quagga/ospf6d(ospf6_lsupdate_recv+0xd0) [0x80535a6] 2007/12/02 19:33:30 OSPF6: [bt 10] /usr/lib/quagga/ospf6d(ospf6_receive+0x249) [0x8055940] 2007/12/02 19:33:30 OSPF6: [bt 11] /usr/lib/libzebra.so.0(thread_call+0x67) [0xb7ed1f54] 2007/12/02 19:33:30 OSPF6: [bt 12] /usr/lib/quagga/ospf6d(main+0x2ce) [0x8052460] 2007/12/02 19:33:30 OSPF6: [bt 13] /lib/libc.so.6(__libc_start_main+0xe0) [0xb7d53050] 2007/12/02 19:33:30 OSPF6: [bt 14] /usr/lib/quagga/ospf6d [0x80520c1]

I got sick of it, and submitted a bug report on the package.  I suspect it will be routed to Quagga's bugzilla.

Seriously, why do folks like it?  OSPF is far superior.  For those implementing IPv6, I don't want to hear any whining about ships-in-the-night routing and precious router memory.  Modern routers have more than enough…

Anyway, here's my list of issues with IS-IS:

Too many TLVs!

It's all very wasteful by default.  For example, TLV types 128 and 130 carry IP address/netmask data with narrow (6-bit) metric values.  TLV 135 (extended IP reachability) does the same thing, but with sub-TLVs and wide (24-bit) metric values.  Both are advertised by default in L1 and L2 areas, and.. get this, as a result, TLV 135 is ignored.  Using JUNOS' wide-metrics-only directive suppresses all but type 135.  However, as 135 has no Internal/External bit, L1/L2 routers advertise L1 routes into L2 areas since they are seen as all internal.  The Up/Down bit saves us from loops, this time!  Anyway, Joseph M. Soricelli states on page 184 of the JNCIS: Juniper Networks Certified Internet Specialist Study Guide (JNO-303):

The reason for the separate TLVs, as well as the history behind their use, is outside the scope of this book.

I bet it's politics as usual.

Route Leaking

In IS-IS, external L1 routes aren't advertised out of the level, at all!  The L1/L2 routers won't do it, by default, unless you configure route policies to leak the routes out into the L2 area.  Using wide metrics will accomplish this, too.  The default just seems silly, though.. OSPF has no problem with this!  An ASBR in a non-backbone transit area sends out a type 5 LSA with is spread through the whole OSPF network.  Even stub areas (well, NSSA) support this with type 7's that are translated to 5's at the ABR.

These types of limits just seem unnecessary, to me.

MTU of 1492

All links that run IS-IS must support a minimum of a 1492 byte MTU.  Why are we stuck with this archaic limit in this day and age?  More and more tunnels, VPN and other, are being used in enterprise and service provider networks, and may not be able to accommodate this requirement.

Furthermore, the method that IS-IS determines whether a link is capable of 1492 is fairly humorous, and wasteful.  Each Hello PDU is padded with type 8 TLVs, which add on chunks of data (255 bytes per TLV) to reach 1492 bytes.  If the link doesn't support 1492, the Hellos are dropped and an adjacency isn't formed.  This just seems wasteful, to me.  Fortunately, JUNOS supports "smart" padding so such TLVs are only included until the adjacency comes up.  I don't know about IOS, though.

Vestigial Metrics

I suppose vestigial is the wrong word to use, since NO router vendor has EVER implemented them.  I'm referring to the delay, expense, and error metrics (1 wasted byte, each) in TLVs of type 128 and 130.  For those who say OSPF is "chattier" than IS-IS, these wasted bytes add up!

802.3 LLC

IS-IS on an Ethernet network uses the 802.3 w/LLC frame type instead of a more normally-used Ethernet-II type w/a unique ethertype.  I suppose this is a result of DEC developing the protocol so it could be used with DECnet phase V, which supports ISO addressing (see next section).

NSAP Addresses

NSAP addresses (ugly things like 49.0001.0101.0000.0003.00) are used for router identification, as a result of IS-IS being built around the OSI stack.  These addresses are cumbersome to work with, and really have no place in IP or IPv6 networks.  Although, many telcos still deploy services using CLNP with IS-IS, so I guess this makes sense for them.

Default Routes

Since L2 routes aren't advertised into L1 areas, a default route (::/0 or 0/0) is used to reach destinations outside the L1 area.  The L1/L2 routers set the attached bit in the TLVs they send into the L1 area, and the L1 routers generate default routes pointing to the nearest L1/L2 router.  Why do we have to rely on default routes to reach destinations in our own administrative domain?  It just seems like a bad design, but does cut down on database size.  The equivalent of this is a stub area in OSPF, which is only used if old routers (limited on memory) are used.

Address Summarization

Unlike OSPF, where the address summarization just plain sucks, IS-IS doesn't do it at all!  If you really want to do this in JUNOS, you just use aggregate routes and leaking.. eww.

So, anyway, I have yet to see a reason to use IS-IS over OSPF in any type of environment.  And if you're about to bring up ships-in-the-night again, new implementations of OSPFv3 should support both IPv4 and IPv6 without the need for v2, at all.  It's the best of both worlds!

Phew, I setup the Christmas tree.  It looks nice, but needs ornaments.  I'll tackle that another day…

Unfortunately, since this is its third year of use, it's starting to shed a bit, and I think next year I'll be forced to obtain a replacement.  Oh well.