Postcards from Semaphore

I ordered a passive heatsink for system-on-chip of the Raspberry Pi 3 model B. Since it fits well I'll share the details:

Order

• Fischer Elektronik ICK S 14 X 14 X 10 heatsink (Element 14 catalogue 1850054, AUD3.70).

• Fischer Elektronik WLFT 404 23X23 thermally conductive foil, adhesive (Element 14 catalogue 1211707, AUD2.42 ).

Install

To install you need these parts: two lint-free isopropyl alcohol swabs; and these tools: sharp craft knife, a anti-static wrist strap.

Prepare the heatsink: Swab the base of the heatsink. Wait for it to dry. Remove the firm clear plastic from the thermal foil, taking care not to get fingerprints in the centre of the exposed sticky side. Put the foil on the bench, sticky side up. Plonk the heatsink base onto the sticky side, rolling slightly to avoid air bubbles and then pressing hard. Trim around the edges of the heatsink with the craft knife.

Prepare the Raspberry Pi 3 system-on-chip: Unlug everything from the RPi3, turn off the power, wait a bit, plug the USB power lead back in but don't reapply power (this gives us a ground reference). If the RPi3 is in a case, just remove the lid. Attach wrist strap and clamp to ethernet port surround or some other convenient ground. Swab the largest of the chips on the board, ensuring no lint remains.

Attach heat sink: Remove the plastic protection from the thermal foil, exposing the other sticky side. Do not touch the sticky side. With care place the heatsink squarely and snuggly on the chip. Press down firmly with finger of grounded hand for a few seconds. Don't press too hard: we're just ensuring the glue binds.

Is it worth it?

This little passive heatsink won't stop the RPi3 from throttling under sustained full load, despite this being one of the more effective passive heatsinks on the market. You'll need a fan blowing air across the heatsink to prevent that happening, and you might well need a heatsink on the RAM too.

But the days of CPUs being able to run at full rate continuously are numbered. Throttling the CPU performance under load is common in phones and tablets, and is not rare in laptops.

What the heatsink allows is for a delay to the moment of throttling. So a peaky load can have more chance of not causing throttling. Since we're only talking AUD7.12 in parts a passive heatsink is worth it if you are going to use the RPi3 for serious purposes.

Of course the heatsink is also a more effective radiator. When running cpuburn-a53 the CPU core temperature stabilises at 80C with a CPU clock of 700MHz (out of 1200MHz). It's plain that 80C is the target core temperature for this version of the RPi3's firmware. That's some 400MHz higher than without the heatsink. But if your task needs sustained raw CPU performance then you are much better off with even the cheapest of desktops, let alone a server.

Cisco 2500-series RJ45

There used to be a variety of specifications for presenting a RS-232 signal on a RJ-45 socket. There is one predominant survivor: the pinout of the Aux socket of the cisco Systems 2500-series routers (from back when Cisco had no leading capital letter, being short for San Francisco).

The pinout of the socket is:

RTS and TxD are not valid until DTR is asserted: the device might be off and they may be floating. RTS indicates that there is enough buffer to receive more data. TxD is used to transmit data. Data is not sent until CTS is asserted. RxD and CTS are not valid until DSR is asserted.

The cabling is straightforward:

1 CTS ---- RTS 8
2 DTR ---- DSR 7
3 TxD ---- RxD 6
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 4
6 RxD ---- TxD 3
7 DSR ---- DTR 2
8 RTS ---- CTS 1

You can see that the presentation of signals to pins has been carefully thought out. By flipping over the RJ-45 plug at one end when crimping the RJ-45 patch lead we can connect one Aux interface to another Aux interface. Cisco call this transposition a "rolled" UTP cable.

This trick has one downside. You'll recall that a 568B UTP cable twists the wires 1,2; 3,6; 4,5; 7,8 and a 568A UTP cable twists the wires 1,2; 3,6; 4,5; 7,8. That is, the TxD and RxD signals are not carried on the same pair as the Gnd. That is going to affect performance. I think that is acceptable: if you want performance on unshielded twisted pair then that is why RS-422 exists.

The 2500-series of devices used a speed of 9600 bits per second. Each ASCII character used 1 start bit-time, 8 data bits, no parity bit, and 2 stop bit-times. Later devices used only 1 stop bit-times for greater compatibility with common settings.

The command line of early devices would clear the top bit of received ASCII characters, allowing 7 data bits and either odd or even parity to be understood by the command processor (the screen would show gibberish, but from a 7E1 terminal you could blindly type the commands to set 7E1 for the terminal setting and the display would then work. Although a useful hack at the time, today it means that international characters are best avoided when using the Cisco IOS command line.

Console ports do not do handshaking. They connect CTS to RTS. They pull up DTR to asserted as long as the chassis is powered. They ignore DSR.

IBM PC/AT DB-9

There is of course another popular presentation of RS-232 signals: the D-9 plug of a IBM PC/AT. The usual RS-232 connector is a D-25 socket, unfortunately the IBM PC used that for the Centronics parallel connector for a printer (the usual Centronics connector was too side for the IBM PC interface slots). So the IBM PC used a D-25 plug for the RS-232 connector to avoid cabling errors. The IBM PC/AT updated that to use a D-9 plug, allowing the serial and parallel interfaces to be presented using one slot (the "Super I/O" cards).

The pinout of the IBM PC/AT D-9 connector is:

IBM PC to Cisco console

So how do we interface these two? There are obviously two choices: allowing for a standard patch lead and allowing for a rolled patch lead. Cisco chose to allow for a rolled patch lead. Thus a RB-9/RJ-45 backshell, a rolled cable, and another RB-9/RJ-45 backshell could be used to interconnect two IBM PC/AT.

1 CTS ---- CTS 8 ---- RTS 7
2 DTR ---- DSR 7 ---- DSR 4
3 TxD ---- RxD 6 ---- RxD 3
4 Gnd ---- Gnd 5 ---- Gnd 5
5 Gnd ---- Gnd 4 ---- Gnd 5
6 RxD ---- TxD 3 ---- TxD 2
7 DSR ---- DTR 2 ---- DTR 6
8 RTS ---- RTS 1 ---- CTS 8
                 nc-- DCD 1
                 nc-- RI  9

You can see that for this cable to work the application has to be configured to ignore Data Carrier Detect. If you make your own RJ45/DB9 backshells then you may wish to crimp DCD(1) and DSR(4) on the DB9 connector to DSR(7) on the RJ45 connector.

Avoiding the rolled cable

The rolled cable is key to a flexible system for interconnecting RS-232 devices. However the importance of RS-232 has faded. About the only thing it is used for these days is for the console of networking and embedded devices. Flexibility for other applications doesn't have the attraction it once did.

For connecting a computer to a console the rolled cable is painful: using a standard patch lead would be far superior. If you needed a longer cable you could simply use one from the stock of standard UTP cables.

This is the approach taken by Juniper Networks. They provide a backshell and a standard UTP cable. The pinout of the backshell is:

1 CTS ---- RTS 7
2 DTR ---- DSR 4
3 TxD ---- RxD 3
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 5
6 RxD ---- TxD 2
7 DSR ---- DTR 6
8 RTS ---- CTS 8
      nc-- DCD 1
      nc-- RI  9

Again, if I was constructing this myself I would pull up DCD if the far end is available. That would allow lines to clear down properly if the far end powers down.

1 CTS ---- RTS 7
2 DTR --+- DSR 4
        +- DCD 1
3 TxD ---- RxD 3
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 5
6 RxD ---- TxD 2
7 DSR ---- DTR 6
8 RTS ---- CTS 8
      nc-- RI  9

The USB console

Computers no longer come with RS-232 ports. Network engineers carry a RS-232/USB dongle. So why not provide a USB B connector which carries a Data Class Interface USB profile. Cisco Systems use a Mini B connector. This will appear as a /dev/ttyUSB… if connected to a Linux system.

I have yet to try it, but there shouldn't be anything preventing plugging a whole switch stack of USB consoles into a single USB hub. A small embedded computer like a Raspberry Pi can then used as a basic console server.

RS-232 will be with us in the embedded space for a long time. It is very easy to initialise a RS-232 UART and so it is an ideal way to output messages from very early in the boot process. For this application there is little justification for the high voltage levels of RS-232 and many boards present 5V or 3.3V levels (that is, they have the UART but not the MAX232 chip). Those signals can be run directly into the RS-232 inputs of a Prolific or similar RS-232/USB UART (again, lacking a MAX232 ship).

Introduction

The maximum transmission unit is the largest number of network-layer bytes you can send and receive on an interface. ‘Network layer’ implies that the count does not include any link layer framing, such as ethernet headers or SDH segment overhead, but does include network layer headers, such as IP or IPv6 packet headers.

The ethernet MTU is 1500. In practice all ethernet interfaces can send slightly more than this, to allow for link-layer extension headers such as VLAN or MPLS tags.

Many gigabit ethernet interfaces can send much larger packets: typically, but not always, a little over 9000 bytes. These ‘jumbo frames’ are not standardised by the IEEE, as in their view an ethernet should interoperate with all other ethernet. The academic and research networks discussed jumbo frames at an Internet2 Joint Techs Meeting and declared that their networks would pass jumbo frames of 9000 bytes, this decision was adopted by APAN and TERENA and also seems to have become the commercial practice.

That meeting made one other decision: the aim of jumbo frames is to present a 9000 byte path from host interface to host interface. This means the engineering practice with jumbo frames is slightly different to that with standard frames — when running tunnels you engineer the network to present 9000 bytes to traffic passing through the tunnel.

So how to tell if you have a 9000 byte clean path? Use an ICMP Echo Request to send a jumbo frame, setting IP's Do Not Fragment bit. If you get a ICMP Echo Reply then the path cannot have fragmented your jumbo frame.

That should be simple enough. Unfortunately ping programs differ as to what their ‘size’ parameters indicate. Network engineers want the size to be the entire network layer, but it is simpler to implement ‘size’ as the number of bytes in the ICMP Echo Request payload. An IPv4 header without options is 20 bytes, an ICMP header is 8 bytes, an IPv6 header without options is 40 bytes, an ICMP6 header is 4 bytes.

Linux, configuring MTU

From the command line:

$ ip link set dev eth0 mtu 9000

In Debian edit /etc/network/interfaces:

interface eth0
    mtu 9000

In Red Hat edit /etc/sysconfig/network-scripts/ifcfg-eth0:

MTU=9000

In NetworkManager edit /etc/NetworkManager/system-connections/eth0:

[802-3-ethernet]
mtu=9000

There is a DHCP option for Interface-MTU, which many Linux distributions implement. All IPv6 autoconf hosts will automatically set interface's MTU for IPv6 traffic. In practice Linux device drivers do not implement differing MTUs for IPv4 and IPv6 traffic.

$ ip link show dev eth0
1: eth0:  mtu 9000 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff

Linux ping, IPv4

size = mtu − icmpv4_header − ipv4_header
size = mtu − 8 − 20
size = mtu − 28

To check a 1500 MTU:

$ ping -c 1 -M do -s 1472 remote.example.edu.au

To check a 9000 MTU:

$ ping -c 1 -M do -s 8972 remote.example.edu.au

Linux ping6, IPv6

size = mtu − icmpv6_echo_header − icmpv6_header − ipv6_header
size = mtu − 4 − 4 − 40
size = mtu − 48

To check a 1500 MTU:

$ ping6 -c 1 -M do -s 1452 remote.example.edu.au

To check a 9000 MTU:

$ ping6 -c 1 -M do -s 8952 remote.example.edu.au

Cisco, configuring MTU

Cisco IOS allows MTU to be set for an interface, which changes the default for all network layer packets which use that interface:

interface Ethernet0
    mtu 9000

It also allows the MTU to be specified for each network-layer protocol, in the rare cases where that is desirable:

interface Ethernet0
    ip mtu 9000
    ipv6 mtu 9000

Router> show interfaces Ethernet 0 | include MTU
  MTU 9000 bytes, BW 10000 Kbit, DLY 1 msec,

Router> show ip interface Ethernet 0 | include MTU
  MTU is 9000 bytes

Router> show ipv6 interface Ethernet 0 | include MTU
  MTU is 9000 bytes

Cisco ping, IPv4

datagram_size = mtu

To check a 1500 MTU:

Router> ping ip
Target IP address: remote.example.edu.au
Repeat count [5]: 1
Datagram size [100]: 1500
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 
Type of service [0]: 
Set DF bit in IP header? [no]: y
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 1, 1500-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds:
Packet sent with the DF bit set
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

To check a 9000 MTU:

Router> ping ip
Target IP address: remote.example.edu.au
Repeat count [5]: 1
Datagram size [100]: 9000
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 
Type of service [0]: 
Set DF bit in IP header? [no]: y
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 1, 9000-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds:
Packet sent with the DF bit set
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

Cisco ping, IPv6

datagram_size = mtu

Note that Cisco IOS does fragmentation of transmitted ICMP. If you send a ICMP request of 9000 bytes over a 1500 byte egress interface then the Echo Request will appear as multiple 1500 byte packets. If you send a ICMP request of 9000 bytes over a 9000 byte egress interface then the ICMP Echo Request will appear as one packet. In this case, any downstream device with a MTU of 1500 will fail to forward the packet, and thus can be discovered. In short, check the routing and the MTU on the interface prior to sending ICMP Echos.

Router> show ipv6 route 2001:DB8:0001:0001::1
IPv6 Routing Table - 1 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C   2001:DB8:0001:0001::/64 [0/0]
     via ::, Ethernet0

Router> show ipv6 interface Ethernet 0 | include MTU
  MTU is 9000 bytes

To check a 1500 MTU:

Router> ping ipv6
Target IPv6 address: remote.example.edu.au
Repeat count [5]: 1
Datagram size [100]: 1500
Timeout in seconds [2]: 
Extended commands? [no]:
Sweep range of sizes? [no]: 
Type escape sequence to abort.
Sending 1, 1500-byte ICMP Echos to 2001:DB8:0001:0001::1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

To check a 9000 MTU:

Router> ping ipv6
Target IPv6 address: remote.example.edu.au
Repeat count [5]: 1
Datagram size [100]: 9000
Timeout in seconds [2]: 
Sweep range of sizes? [no]: 
Type escape sequence to abort.
Sending 1, 9000-byte ICMP Echos to 2001:DB8:0001:0001::1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

Juniper, IPv4

ipv6_n = mtu - icmpv6_header
= mtu - 8

JUNOS can globally set the source IP address for packets generated by the router to that of the lo0.0 interface. This saves considerable messing about.

system {
    default-address-selection;
}

However when testing a link we want to use the addressing from the link, not from the router's control plane. Then if the remote router's forwarding table isn't populated it can still has a routable address for the ICMP Echo Reply.

Amnesiac> ping bypass-routing interface et-0/0/0.0 …

Software defined networks are big in the data centre: there are many startups because that's where the money is. But SDN is also very useful in the wide area.

Take the vexed issue of SIP handsets at customer sites. What we really want to do is admission control of those handsets' traffic into the Voice QoS class. Then hacked softphones can't run a denial of service into the Voice QoS class.

There's a whole IETF architecture to do this: integrated services. But no one uses it. It is complex, support isn't very widespread, and all the difficult questions are pushed to a "bandwidth broker" which requires too much knowledge of the network topology.

SDN gives us another approach. Set up the IETF Differentiated Services in the core. At the edge do admission control into that DiffServ core. But how to do the admission control when there so little support for IntServ?

The obvious thing to do is for the SIP entity which SIP-routes the call to send a note to the OpenFlow controller, which then puts some rules on the edge switch above the customer to admit the flow into the QoS class (at a minimum: for the specified IP address and UDP port, rewrite the DSCP to EF).

Yeah, all of this is an obvious application of SDNs. But in this age of software patents, that's well worth saying.

Like Russell I spend a lot of time on conference calls. Here's my advice.

• Use the Mute button. "Signal to noise ratio" is a common electronics' concept. So let's keep the noise floor down so that the signal is easily heard. "Automatic gain control" is another common electronics' concept. Your microphone volume will be raised until there is a signal, and if you aren't talking then that signal will be the interesting conversation on the far side of the office.

• Videoconferences are preferred. If you have a regular meeting, then arrange it to use a video conference. This is far superior to phone, but also trickier to set up.

• Introduce yourself upon joining. Someone needs to keep track of the quorum, so when you connect listen for a moment and then at the next break in the conversation say "Hi, Jane joining the Blah Conference, muting now" then press Mute. Because the noise floor changes when you connect you are disrupting people when you join, so it's pointless to try to join without announcing yourself, people just wonder "Who was that?" If you've crashed someone who was speaking then because they know you "muted now" they can continue.

• Don't be late. Timeliness is more prized on audio and video conferences than in real life. So connect before the clock strikes the start time.

• Audio quality matters. A good level of audio, with little background noise, and no breathing noise. You just need one person to mess this up to make a conference a misery. Don't be that person -- everyone is listening to find out who it is that is being so annoying. If you are telephone conferencing then do not use hands free, pick up the receiver. If you are telephone conferencing then use a landline if you at all can.

  For both phone and computer conferences a good headset makes a world of difference. A bad headset is worse that no headset at all, so use a good product. I personally like the Plantronics products for both phones and PCs.

  If you can't use a headset, think seriously about a good microphone, a small mixing desk, and a monitor-quality set of headphones. I've used this and with almost all conferences people remarked on the excellent quality.

  Output audio is important too. If you are using a real conferencing system with echo suppression which works, then put in decent speakers, like those of a hifi system.

  If you are teleconferencing with a group of people surrounding a table then don't just plonk the corporate phone in the middle of the table and hope for the best. The Polycom SoundStation has an awesome reputation for this task.

• If something has changed, connect early. If you've never conferenced using this facility, connect an hour early. If they've rejigged the conferencing system, connect an hour early. Most systems will let you disconnect and return later.

• Have a backchannel. E-mail, IRC, IM, web forum, whatever. Some way to share electronic materials. Jabber conferences make a good back channel. For huge conferences (and the SARS teleconferences had hundreds of people) use the backchannel for people to indicate a desire to speak and for the chair to call them. Also useful in huge conferences for collecting the attendees and apologies. For truly massive conferences pay a typist to transcribe, as there's always one site which will be having difficulty at any one moment. If you find yourself doing all the work in the backchannel then reconsider if this should have been a teleconference or videoconference at all.

• Have a pre-filled archive. Use a wiki page. Require people to submit their electronic materials there beforehand (and minutes beforehand is fine). That also becomes a good place to state the agenda and to keep the minutes.

Some additional advice for videoconferences with lots of people:

• Videoconferences are preferred. If you have a regular meeting, then arrange it to use a video conference. This is far superior to phone, but fiddlier, so it's really only worth it for regular meetings.

• Have a chair. Someone to announce the agenda item. Someone to call on people to speak. The chair needn't be the decision-maker, quite the reverse. In that case the decision-maker can open with "Thank you all for coming, Fred will be coordinating the conference, so please wait until he calls upon you to speak." Fred needs some political nouse so that he calls the correct people in at the correct time and some knowledge of the issue so that he can spot people how are about to make a valuable contribution.

  The person calling the conference should have arranged someone to take the minutes. Doing this a backchannel can be useful.

• Put your hand up. If you want to speak, raise your hand. When the chair calls on you, then unmute and say your piece.

• You are on TV. Come to the point and stay on it. Then get off. Presenting your view clearly is important, so think over what you are going to say. The sort of cultural verbiage which takes place in person can become very boring, Just like when watching the TV, bored people get cynical.

• Good audio is more important than video. Get the audio right and the video can be terrible. Get the audio wrong and it doesn't matter how good the video is.

• Good images are more important than refresh rate. Use a good camera. Then light the scene well. Zoom the camera so that two-thirds of the screen is full of what is important. So if it's just you then most of the screen is your face.

• A lit image is a good image. Your office lighting isn't going to cut it. You need some diffuse lighting coming from behind the camera to stop shadowing your face, this can be simple as a low wattage lamp placed behind your laptop and angled to put light up the wall.

  Don't use LED lighting, yet. Light has colour. The videoconferencing system adjusts for this. In theory this is done automatically, but finding the setting and hardcoding it to your lighting technology and your country's AC frequency is a good idea. Unfortunately, there's usually not a profile for LED lighting.

• Videoconferences have more things to break. Have a backup plan. H323 and SIP videoconferencing systems which allow people to dial in from the PSTN are great for serious conferences as they readily have a backup plan to failing client video setups -- ring in.

• Use an appliance. One of the small videoconferencing units. Or a small computer which isn't your main development machine. I've rarely upgraded my Linux distribution and had videoconferencing applications work without fiddling. That's not usually the applications fault, but the breakage of the Linux audio or video systems or drivers in new and interesting ways.

• Have an expert immediately available. Big videoconferencing users will have experts on call. But a medium sized videoconference should have a person who can drop out to solve the connection issues of a party. The availability of an expert makes a huge difference and is the best reason for outsourcing your videoconferencing (and no, not a plug for outsourcing to my employer, rather just what we found we had to do to make a videoconference work when it has many hundreds of people).

You'll notice how little of this has to do with the conferencing technology you use.

The recommended best practice for addressing point to point links in IPv6 has been under discussion.

The original notion was simply to use EUI-64 and let the addresses autoconfigure. The problem with this approach is that the IP addresses of router interfaces often end up coded within parts of the router's configuration. Those hard-coded addresses then hurt when the interface becomes faulty, is replaced, and a different EUI-64 address is derived from the new interface's different MAC address. Hard-coding MAC addresses is a poor idea; protocols which have required that (eg, DECNet) were historically operationally painful.

A better notion is to use a /64 and configure …:1 at the more central interface and …:2 at the further interface. Not everyone is taken with the waste of addressing of this approach. IPv6 is big, but it won't be big for too long if addressing is squandered.

At the other extreme is a /127, using special features to nullify the Subnet Router Anycast Address (which no one much uses). The notion is problematic enough to warrant yet another Considered Harmful. Supporting a /127 is one more checkbox you need to test during equipment validation. And what if you have a nice bit of kit without the feature?

The suggestion which makes most sense to me is to use a /124. This has enough addresses to avoid any reuse of special addresses. It is not as wasteful as a /64. Best of all it is operationally sane, since four bits¹ make one textual hexadecimal character in the IPv6 address. So the more central router can be …:abc1/124 and the further router can be …:abc2/124. That's a lot easier to manage than dealing with non-character boundaries.

 —
¹ Four bits is commonly called a nybble, back-formed from eight bits making up a byte.

Every language has its dark feature, something only for the use of wizards. In Cisco IOS that feature is the "redistribute" command. If you are a mere mortal rather than a routing god, then using "redistribute" in your configuration is a sign that you're about to make a serious mistake.

"Redistribute" copies routes from one routing process to another. You often see it used like this:

 ! Do not code like this...
 router ospf 65000
  ! Copy all static routes into this process
  redistribute static

The really dangerous usage looks like this:

 ! Do not code like this...
 router ospf 65000
  ! Copy all routes from the BGP process, a fool's way of getting
  ! a BGP-leaned default route into OSPF.
  redistribute bgp 65000

Add a few more routers and you get self-sustaining, flapping routes. Routes that don't indicate reachability. Whoops.

Whenever you use "redistribute" replace it with a "network" statement. If you were redistributing to inject a default route, then replace it with a "default-information" statement.

People resist this advice, because it replaces the "redistribute" one-liner with one "network" command per route. Suck it up, long and correct beats short and wrong.

 ! Do it this way
 interface ethernet 0
  ip address 10.1.1.255 255.255.255.0
 interface ethernet 1
  ip address 10.1.2.255 255.255.255.0
 interface ethernet 2
  ip address 10.1.3.255 255.255.255.0
 router ospf 65000
  network 10.1.1.255 0.0.0.255 route-map OSPF-NETWORK-ROUTE
  network 10.1.2.255 0.0.0.255 route-map OSPF-NETWORK-ROUTE
  network 10.1.3.255 0.0.0.255 route-map OSPF-NETWORK-ROUTE
  default-information originate route-map OSPF-DEFAULT-ROUTE

Note that each "network" line exactly matches a route. A beginner's error is to have the "network" statement match your entire IP allocation. That appears to work, but fails when the network topology gets complex (ie, just when you've got a huge handful of routers which need to be reconfigured).

Another beginner's error is to list routes which are not originated from this router. You don't need to list another router's routes. Those are learned via the routing protocol.

The route-maps apply attributes to the route. For the OSPF routes the interesting attribute is the 32-bit tag. That can be usefully set to the site in which the route originates.

For BGP routes the interesting attributes are the MED and the community values. Set the MED to the number of deciseconds of delay on the link (from "ping"). Set communities to indicate the originating router and the originating site, plus anything else which you might need in your routing policy (such as if the route was learned from a financially costly link).

The conditions for a route advertisment when using this technique are important to know. A route is advertised by our process "ospf 65000" iff there is a "network" statement and the prefix in the statement exactly matches a prefix in the *forwarding* table. The gating of all routes through matches in the forwarding table is what prevents routing loops, as no route will be advertised that isn't actually in use. The "redistribute" command does not look into the fowarding table at all.

Similarly, "default-information originate" looks for a 0.0.0.0/0 route in the forwarding table before adding 0.0.0.0/0 to the routing process.

You often need to have a route for your entire IP allocation. Inject that route like this:

 ! Do it this way
ip route 10.1.0.0 0.0.255.255 254
router bgp 65000
 network 10.1.0.0 mask 255.255.0.0 route-map BGP-ORIGINATE-ROUTE

The administrative distance of 254 indicates that this route will lose should there be a matching route learned from any other routing process. It is the worst sort of magic number, in that it's not magic at all. It's actually avoiding 255, which is a magic number.

Locally-assigned MAC addresses best start with 06. You should use a locally-assigned address when you need an arbitrary MAC address, such as for ethernet-based failover schemes.

Configure the access point with only WPA2 and CCMP. WPA2 may be referred to as "IEEE 802.11i". CCMP includes AES encryption, so CCMP may be referrred to as "AES". Don't configure support for the older TKIP encryption. Don't configure support for WPA or WEP or Open (no security at all).

A home network will want to use pre-shared keys. This also also called "WPA2-Personal". The resistance of WPA2-PSK to attack depends entirely on the ability of the pre-shared key to resist a dictionary attack: that is, how random the key is and how long the key is.

How long is needed? Each character gives about 2.5 bits of binary key. You want something more than 33 characters (90bits) and probably more than 50 characters (128b). That's a lot of typing which needs to be exactly right. Cut-and-paste from a USB stick seems to be called for.

How random is needed? Really random. To make life easy grab it from Linux's /dev/random. This has issues, but not nearly as many as a human attempt to write a random string:

$ pwgen -s 50 1
icvxgsQI8TdyECJcVWrpmB1djkz2UIdIqrj0trwabcxMAc50Nw

The biggest hurdle moving to WPA2 has been backward compatiblity. That now doesn't seem to be a problem. Microsoft have shipped WPA2-PSK support as part of Service Pack 3 for Windows Xp. There is a specific download for WPA2 support in Windows Xp SP2. Linux's Network Manager and wpa_supplicant support WPA2-PSK, as do nearly all device drivers. Even pre-WPA2 chipsets seem to have support, but with the AES encryption done in software. Apple support WPA2.

You need to watch older access points, as these will do AES in software. There's a lot of headroom in PC CPUs, but none at all in access point CPUs. So activating WPA2 on a access point which lacks hardware encryption can really hurt throughput. Of course, some mongrel stealing your Internet bandwidth also hurts performance :-)

Whilst reconfiguring your access point you may want to consider if you have any 802.11b devices. If not you might to configure only 802.11g to gain additional performance from some protocol enhancements made for 802.11g which are disabled when being backwardly compatible.

Verify correct operation by checking the ESSID broadcast. There is only one "IE" and it is "WPA2" (and not additionally "WPA" or "WEP"). There is only one "Cipher" it is "CCMP" (and not "TKIP").

# iwlist eth1 scan
          Cell 01 - Address: 00:11:22:33:44:55
                    ESSID:"example"
                    Mode:Master
                    Frequency:2.462 GHz (Channel 11)
                    Quality=37/70  Signal level=-58 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s
                    Extra:bcn_int=100
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK

Once you've got the access protected a lot of the "raising the bar" techniques that were needed when insecure WEP was the only choice can be removed. Broadcast the SSID, allow any MAC address, and so on. This gives a payoff in convenience in return for the inconvenience of entering the long, random WPA2-PSK key.

Bought a red+white pair of these for E's bike. The integral reflector allowed me to legally remove the manufacturer's reflectors and mount the lights in their place. This saves a lot of stuffing about, as there is little space for additional mountings on small kid's bikes. The light flashes in a complicated rhythm, making the bike very noticable.

Update: LEDs improve every year, manufacturer's leapfrogging each other. As of 2013 I'd now recommend the Portland Design Works' Radbot 1000. It's bright, has a reflector. The only downside is the low run time on its AAA batteries, so rechargables are required.