1. Paring Down “Watt’s Switched On” on a Client’s Network

    As part of carbon reduction for a client, Creative Concern, I’ve been working on:

    • leased-line router consolidation
    • server consolidation
    • network switch consolidation (using D-Link’s line of green ethernet switches)
    • power management on desktop computers (no screen saver but screen backlight switch-off, sleep when idle, scheduled shutdown at 6pm)
    • night-time network scan to determine devices not shut down

    The network scan is a particularly fun one: MacOS and modern printers all respond to multicast DNS, and so finding devices which are switched on is quite simple. Every night an email is sent (by one of the servers which stays on 24/7) to the staff naming and shaming the devices which were left powered up:

    #!/bin/bash
    
    avahi-browse -at \
      | cut -c 14-59 \
      | sort \
      | uniq \
      | mail -s "Named and Shamed: devices left on overnight" everyone@client
    

    I’ve removed a few grep -v statements which filter out things like the servers which are meant to be left on overnight, but those are the essentials.

    Having fitted a smart meter the client has access to power usage graphs and history, and I’m pleased to be able to report that they look to be on course for a 10% saving in 2010! Here is the screenshot from the meter just now:

    I am still to explore:

    • consolidating the font, finance and project management system servers (currently all require different versions of OS X)
    • wireless network access point consolidation (can just two APs cover the entire office area?)
    • more network switch consolidation (eliminate all desktop switches?)
    • CPU scaling on servers to use power-saving governors outside office hours

    I estimate that we might achieve an additional 10% saving if we can do all these things, but could be hampered by what’s feasible in the office with the technologies available.

    0 notes
    Comments (View)
  2. NAT-safe IPv6 Tunnel from Mac OS X to Linux Server

    Here is how I routed myself a block of IPv6 to my laptop, wherever I am in the world! Note that I deliberately route myself an entire /64, but only allow a /128 through tinc (to reduce the amount of junk I might drown in). It should be relatively trivial to swap addresses if necessary in future.

    Mac OS X Laptop

    tinc.conf

    Name = laptop
    ConnectTo = server
    DeviceType = tun
    Mode = router
    

    tinc-up

    #!/bin/sh
    ifconfig $INTERFACE up
    ifconfig $INTERFACE inet6 add 2001:0db8:1234:5678:cafe:babe:feed:face prefixlen 64
    route add -inet6 2001:0db8:1234:5600::1 -prefixlen 56 -iface $INTERFACE
    route add -inet6 :: -prefixlen 0 2001:0db8:1234:5600::1
    

    tinc-down

    #!/bin/sh
    route delete -inet6 :: -prefixlen 0
    route delete -inet6 2001:0db8:1234:5678:: -prefixlen 64
    route delete -inet6 2001:0db8:1234:5678:cafe:babe:feed:face
    ifconfig $INTERFACE inet6 delete 2001:0db8:1234:5678:cafe:babe:feed:face prefixlen 64
    ifconfig $INTERFACE down
    

    ~/bin/ipv6

    #!/bin/sh
    sudo /opt/local/sbin/tincd -D -c ~/.tinc
    

    Debian Linux Server

    nets.boot

    tunnel-5600
    

    tunnel-5600/tinc.conf

    Name = server
    DeviceType = tun
    Mode = router
    Subnet = 0:0:0:0:0:0:0:0/0
    

    tunnel-5600/tinc-up

    #!/bin/sh
    ip addr add 2001:0db8:1234:5600::1/56 dev $INTERFACE
    ip link set $INTERFACE up
    

    tunnel-5600/tinc-down

    #!/bin/sh
    ip addr del 2001:0db8:1234:5600::1/56 dev $INTERFACE
    ip link set $INTERFACE down
    

    Common

    hosts/laptop

    Subnet = 2001:0db8:1234:5678:cafe:babe:feed:face/128
    -----BEGIN RSA PUBLIC KEY-----
    SNIP
    -----END RSA PUBLIC KEY-----
    

    hosts/server

    Address = 192.168.1.1
    Subnet = 0:0:0:0:0:0:0:0/0
    
    -----BEGIN RSA PUBLIC KEY-----
    SNIP
    -----END RSA PUBLIC KEY-----
    
    Notes
    Comments (View)
  3. Rapid Migration

    Behold the power of BGP!

    64 bytes from 193.142.245.198: icmp_seq=5 ttl=49 time=59.927 ms
    92 bytes from mort.m.faelix.net (193.142.245.108): Destination Net Unreachable
    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
     4  5  00 5400 4a31   0 0000  36  01 5e84 10.26.26.133  193.142.245.198 
    
    Request timeout for icmp_seq 6
    92 bytes from mort.m.faelix.net (193.142.245.108): Destination Net Unreachable
    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
     4  5  00 5400 3942   0 0000  36  01 6f73 10.26.26.133  193.142.245.198 
    
    Request timeout for icmp_seq 7
    64 bytes from 193.142.245.198: icmp_seq=8 ttl=49 time=56.130 ms
    

    Under three seconds of down-time.

    Notes
    Comments (View)
  4. IPv6/BGP Tunnel to Hurricane Electric on Debian with Quagga

    The IPv6 Internet is not immune to breakage and so it seems prudent right now to ensure good connectivity to the big providers. Faelix takes IPv6 transit from TINet, but the possibility of a free 6-in-4 tunnel to Hurricane Electric as a backup path is too good to pass up.

    Having put in my request to HE’s tunnelbroker.net I waited… and within 12 hours had a positive response that it was ready:

    Looks good, tunnel and BGP configured on our side. You'll peer with ::1
    of the tunnel's /64 allocation, and our ASN is 6939.
    

    Here are some pseudonymised details:

    Server IPv4 address:  216.66.84.50
    Server IPv6 address:  2001:0db8:1234:5678::1/64
    Client IPv4 address:  192.0.2.128
    Client IPv6 address:  2001:0db8:1234:5678::2/64
    

    Here is what I put in /etc/network/interfaces:

    auto as6369v6to4
    iface as6369v6to4 inet6 v4tunnel
        address 2001:0db8:1234:5678::2
        netmask 64
        endpoint 216.66.84.50
        local 192.0.2.128
        ttl 255
    

    And here is the appropriately pseudonymised example section from Quagga’s bgpd.conf:

    router bgp 65500
     neighbor 2001:0db8:1234:5678::1 remote-as 6939
     neighbor 2001:0db8:1234:5678::1 update-source 2001:0db8:1234:5678::2
     neighbor 2001:0db8:1234:5678::1 remove-private-AS
     neighbor 2001:0db8:1234:5678::1 route-map rm-AS6939tun-v6i in
     neighbor 2001:0db8:1234:5678::1 route-map rm-AS6939tun-v6o out
     address-family ipv6
      neighbor 2001:0db8:1234:5678::1 activate
      neighbor 2001:0db8:1234:5678::1 route-map rm-AS6939tun-v6i in
      neighbor 2001:0db8:1234:5678::1 route-map rm-AS6939tun-v6o out
     exit-address-family
    
    ipv6 prefix-list pl-transit-64-v6i seq 5 deny ::/0
    ipv6 prefix-list pl-transit-64-v6i seq 10 permit ::/0 le 64
    
    ipv6 prefix-list pl-AS41495-v6-to-upstream seq 5 permit 2001:0db8:666::/48 le 64
    
    route-map rm-AS6939tun-v6i permit 10
     match ipv6 address prefix-list pl-transit-64-v6i
     set as-path prepend 6939 6939 6939
    
    route-map rm-AS6939tun-v6o permit 10
     match ipv6 address prefix-list pl-AS41495-v6-to-upstream
     set as-path prepend 65500 65500 65500
    
    0 notes
    Comments (View)
  5. Fucking Idiot Telcos

    Fucking Idiot Telcos

    Notes
    Comments (View)
  6. BGPviz

    Marek always thought BGPlay was nice but BGPviz is simply gorgeous http://www.ris.ripe.net/bgpviz/ #RIPE #BGP

    Notes
    Comments (View)
  7. Jun 6 23:01:50 prince kernel: cogent: no IPv6 routers present
    prince, one of AS41495’s outgoing routers
    Notes
    Comments (View)
  8. Xen Virtual Server Upgrade at Faelix

    faelix:

    Dear Xen Virtual Server Customers,

    On Tuesday next week Faelix expects to receive delivery of thirty servers to massively upgrade existing hosting arrangements across our two data-centres, and plan our expansion into the third and beyond. They say “there’s no such thing as a free lunch”, but Faelix will be giving free upgrades to our valued existing customers: the only thing you’ll notice is that your sites and services run even faster!

    By the end of next week we should have completed load-testing the new equipment. Over the weekend of 6th-7th June we’ll begin commissioning the new equipment in our data-centres, and our plan is to be in a position to migrate your virtual servers onto the newer, faster hardware over the weekend of 13th-14th June. Of course I’ll be in touch with you closer to the time to ensure that work can be carried out at a convenient time to minimise disruption to you.

    If you’ve any questions or concerns, please don’t hesitate to get in touch.

    Notes
    Comments (View)
  9. Major Power Failure at IFL (update 4, closure)

    faelix:

    Scheduled maintenance work has now been completed, and all systems appear to be operational.

    Notes
    Comments (View)