Prolixium dot com: News >> Blog

So, I've been reconfiguring my network over the past few days, starting with IPv6. I thought I was almost done, but then realized that Quagga seems to be picking non-optimal paths via BGP:

*  2001:4830:122d:9::/64  2001:4830:122d:ffff::29  0  100  0 (65300) i
*                         2001:4830:122d:4::a      0  100  0 (65304 65303 65300) i
*>                        2001:4830:122d:ffff::1   0  100  0 (65303 65300) i
*                         2001:4830:122d:ffff::12  0  100  0 (65302 65303 65300) i

starfire_bgpd# show ipv6 bgp 2001:4830:122d:9::/64
BGP routing table entry for 2001:4830:122d:9::/64
Paths: (4 available, best #3, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  2001:4830:122d:4::a 2001:4830:122d:4::11 2001:4830:122d:19::2 \
  2001:4830:122d:ffff::12 2001:4830:122d:ffff::29
  Local
    2001:4830:122d:ffff::29 from 2001:4830:122d:ffff::29 (10.3.4.10)
    (fe80::a03:fe04)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Last update: Sat Jan  5 13:56:49 2008
                                           
  Local
    2001:4830:122d:4::a from 2001:4830:122d:4::a (10.3.4.6)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Last update: Sat Jan  5 13:56:47 2008
                                           
  Local
    2001:4830:122d:ffff::1 from 2001:4830:122d:ffff::1 (10.3.4.2)
    (fe80::a03:fe14)
      Origin IGP, metric 0, localpref 100, valid, confed-external, best
      Last update: Sat Jan  5 13:56:41 2008
                                           
  Local
    2001:4830:122d:ffff::12 from 2001:4830:122d:ffff::12 (10.3.4.3)
    (fe80::a03:fe17)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Last update: Sat Jan  5 13:56:41 2008

Why is it picking the route originated from 10.3.4.2 (nonce)? I think it should pick the one from 10.3.4.10 (scimitar), since the AS_PATH attribute is the shortest. Cisco's BGP path selection algorithm checks AS_PATH on the 4th step, after 1) weight, 2) LOCAL_PREF, and 3) prefer paths not sourced by aggregate-address. Juniper's BGP path selection algorithm (page 277) checks AS_PATH on the 3rd step, after 1) next-hop reachability and 2) LOCAL_PREF.

I don't want another Quagga bug. I've encountered a couple so far :-(

Update: Whoops, forgot that an AS_PATH with confederations act a little differently. I set bgp bestpath as-path confed, which seems to be working.

Here's a good one. dax (FreeBSD 6.2-STABLE) crashed last night with the following:

subdisk8: detached
ad8: detached
g_vfs_done():ad8s3d[READ(offset=27569928192, length=2048)]error = 6
swap_pager: I/O error - pagein failed; blkno 9694,size 4096, error 6
g_vfs_done():ad8s3d[READ(offset=27569930240, length=2048)]error = 6
vm_fault: pager read error, pid 685 (devd)
g_vfs_done():ad8s1a[READ(offset=423264256, length=32768)]error = 6
g_vfs_done():ad8s3d[READ(offset=27569932288, length=2048)]error = 6
vnode_pager_getpages: I/O read error
vm_fault: pager read error, pid 685 (devd)
g_vfs_done():ad8s1a[READ(offset=98304, length=16384)]error = 6
g_vfs_done():ata4: FAILURE - already active DMA on this device
unknown: setting up DMA failed
ata4: FAILURE - already active DMA on this device
unknown: setting up DMA failed
ad8s1a[READ(offset=192741376, length=16384)]error = 6
g_vfs_done():ad8s3d[WRITE(offset=26008551424, length=16384)]error = 6
g_vfs_done():ad8s4d[WRITE(offset=118730604544, length=12288)]error = 6
g_vfs_done():ad8s3d[READ(offset=27569934336, length=2048)]error = 6
g_vfs_done():ad8s3d[WRITE(offset=26008567808, length=16384)]error = 6
g_vfs_done():ad8s1a[WRITE(offset=578174976, length=16384)]error = 6
g_vfs_done():ad8s4d[WRITE(offset=118668230656, length=16384)]error = 6
g_vfs_done():ad8s3d[READ(offset=27569936384, length=2048)]error = 6
g_vfs_done():ad8s3d[READ(offset=27569940480, length=2048)]error = 6
[...]
g_vfs_done():ad8s4d[WRITE(offset=118742908928, length=16384)]error = 6
g_vfs_done():ad8s4d[WRITE(offset=6144000, length=16384)]error = 6
g_vfs_done():ad8s4d[WRITE(offset=65536, length=2048)]error = 6
panic: vinvalbuf: dirty bufs
cpuid = 1

Translation: The ad8 (SATA disk) device detached from the system, and the kernel became upset trying to write to a nonexistant swap device.

This is the second iteration of this crash, and I'm thinking either SATA controller, cable, or drive. I'll probably have Voxel replace the SATA cable, as that's the easiest to do right now.

Happy New Year!

I think I'm going to skip my Year In Review post this time around, mostly because 2007 wasn't terribly remarkable.

I finally finished setting up the replacement for my WRT54GS (OpenWrt Whiterussian RC3) router, which is mostly used for routing wireless traffic and providing switch ports for my HTPC. The replacement hardware is an ASUS WL-500g Premium router running OpenWrt 7.09.

The specifications aren't too shabby. The main feature is 2x USB 2.0 ports on the back of the unit, powered by a VIA 6212 EHCI controller. I'm thinking I'll either use them for Bluetooth or a webcam.

OpenWrt 7.09 (Kamikaze series) is a decent release, except for some fairly annoying issues:

→ There aren't any Quagga packages built for 7.09. I had to manually install the ipks from the 7.06 release, and they seem to work. I haven't found any reason why Quagga was omitted from the list of packages, yet.

→ BusyBox sucks. It's a very, very, very poor substitute for coreutils, fileutils, et al. It also has a ton of bugs. For example, the ifconfig syntax (odd and nonstandard) is the following:

BusyBox v1.4.2 (2007-09-29 09:01:24 CEST) multi-call binary

Usage: ifconfig [-a] <interface> [<address>]

Configure a network interface

Options:
        [add <address>[/<prefixlen>]]
        [del <address>[/<prefixlen>]]
        [[-]broadcast [<address>]] [[-]pointopoint [<address>]]
        [netmask <address>] [dstaddr <address>]
        [hw ether <address>] [metric <NN>] [mtu <NN>]
        [[-]trailers] [[-]arp] [[-]allmulti]
        [multicast] [[-]promisc] [txqueuelen <NN>] [[-]dynamic]
        [up|down] ...

So, I tried to do this:

[root:kamikaze]# ifconfig lo:0 1.2.3.4/32 
[root:kamikaze]# ifconfig lo:0
lo:0      Link encap:Local Loopback   
          inet addr:1.2.3.4  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1

Look at the mask. It defaulted to classful addressing, where the network 1.0.0.0 is defined as a class A network with a 255.0.0.0 (8-bit) subnet mask. Replacing /32 with netmask resolves it, but jeez folks, why can't we just stick with the normal syntax?

→ The network scripts are not IPv6-aware, and have trouble assigning interface aliases during bootup.

Anyway, at least it doesn't lock up like the WRT54GS :P