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.

Yesterday I received a Zodiac FX four 100Base-TX port OpenFlow switch as a result of Northbound Networks' KickStarter. Today I put the Zodiac FX through its paces.

Plug the supplied USB cable into the Zodiac FX and into a PC. The Zodiac FX will appear in Debian as the serial device /dev/ttyACM0. The kernel log says:

debian:~ $ dmesg
usb 1-1.1.1: new full-speed USB device number 1 using dwc_otg
usb 1-1.1.1: New USB device found, idVendor=03eb, idProduct=2404
usb 1-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.1.1: Product: Zodiac
usb 1-1.1.1: Manufacturer: Northbound Networks
cdc_acm 1-1.1.1:1.0: ttyACM0: USB ACM device

You can use Minicom (obtained with sudo apt-get install minicom) to speak to that serial port by starting it with minicom --device /dev/ttyACM0. You'll want to be in the "dialout" group, you can add youself with sudo usermod --append --groups dialout $USER but you'll need to log in again for that to take effect. The serial parameters are speed = 115,200bps, data bits = 8, parity = none, stop bits = 1, CTS/RTS = off, XON/XOFF = off.

The entry text is:

 _____             ___               _______  __
/__  /  ____  ____/ (_)___ ______   / ____/ |/ /
  / /  / __ \/ __  / / __ `/ ___/  / /_   |   /
 / /__/ /_/ / /_/ / / /_/ / /__   / __/  /   |
/____/\____/\__,_/_/\__,_/\___/  /_/    /_/|_|
            by Northbound Networks
Type 'help' for a list of available commands
Zodiac_FX#
Typing "help" gives:
The following commands are currently available:
Base:
 config
 openflow
 debug
 show ports
 show status
 show version
Config:
 save
 show config
 show vlans
 set name <name>
 set mac-address <mac address>
 set ip-address <ip address>
 set netmask <netmasks>
 set gateway <gateway ip address>
 set of-controller <openflow controller ip address>
 set of-port <openflow controller tcp port>
 set failstate <secure|safe>
 add vlan <vlan id> <vlan name>
 delete vlan <vlan id>
 set vlan-type <openflow|native>
 add vlan-port <vlan id> <port>
 delete vlan-port <port>
 factory reset
 set of-version <version(0|1|4)>
 exit
OpenFlow:
 show status
 show flows
 enable
 disable
 clear flows
 exit
Debug:
 read <register>
 write <register> <value>
 exit

Some baseline messing about:

Zodiac_FX# show ports
Port 1
 Status: DOWN
 VLAN type: OpenFlow
 VLAN ID: 100
Port 2
 Status: DOWN
 VLAN type: OpenFlow
 VLAN ID: 100
Port 3
 Status: DOWN
 VLAN type: OpenFlow
 VLAN ID: 100
Port 4
 Status: DOWN
 VLAN type: Native
 VLAN ID: 200

Zodiac_FX# show status
Device Status
 Firmware Version: 0.57
 CPU Temp: 37 C
 Uptime: 00:00:01

Zodiac_FX# show version
Firmware version: 0.57

Zodiac_FX# config

Zodiac_FX(config)# show config
Configuration
 Name: Zodiac_FX
 MAC Address: 70:B3:D5:00:00:00
 IP Address: 10.0.1.99
 Netmask: 255.255.255.0
 Gateway: 10.0.1.1
 OpenFlow Controller: 10.0.1.8
 OpenFlow Port: 6633
 Openflow Status: Enabled
 Failstate: Secure
 Force OpenFlow version: Disabled
 Stacking Select: MASTER
 Stacking Status: Unavailable

Zodiac_FX(config)# show vlans
	VLAN ID		Name			Type
	100		'Openflow'		OpenFlow
	200		'Controller'		Native

Zodiac_FX(config)# exit

Zodiac_FX# openflow

Zodiac_FX(openflow)# show status
OpenFlow Status Status: Disconnected
 No tables: 1
 No flows: 0
 Table Lookups: 0
 Table Matches: 0

Zodiac_FX(openflow)# show flows
No Flows installed!

Zodiac_FX(openflow)# exit

We want to use the controller address on our PC and connect eth0 on the PC to Port 4 of the switch (probably by plugging them both into the same local area network).

Zodiac_FX# show ports
…
Port 4
 Status: UP
 VLAN type: Native
 VLAN ID: 200
debian:~ $ sudo ip addr add 10.0.1.8/24 label eth0:zodiacfx dev eth0
debian:~ $ ip addr show label eth0:zodiacfx
    inet 10.0.1.8/24 scope global eth0:zodiacfx
       valid_lft forever preferred_lft forever
debian:~ $ ping 10.0.1.99
PING 10.0.1.99 (10.0.1.99) 56(84) bytes of data.
64 bytes from 10.0.1.99: icmp_seq=1 ttl=255 time=0.287 ms
64 bytes from 10.0.1.99: icmp_seq=2 ttl=255 time=0.296 ms
64 bytes from 10.0.1.99: icmp_seq=3 ttl=255 time=0.271 ms
^C
--- 10.0.1.99 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.271/0.284/0.296/0.022 ms

Now to check the OpenFlow basics. We'll use the POX controller, which is a simple controller written in Python 2.7.

debian:~ $ git clone https://github.com/noxrepo/pox.git
debian:~ $ cd pox
debian:~ $ ./pox.py openflow.of_01 --address=10.0.1.8 --port=6633 --verbose
POX 0.2.0 (carp) / Copyright 2011-2013 James McCauley, et al.
DEBUG:core:POX 0.2.0 (carp) going up...
DEBUG:core:Running on CPython (2.7.9/Mar 8 2015 00:52:26)
DEBUG:core:Platform is Linux-4.1.19-v7+-armv7l-with-debian-8.0
INFO:core:POX 0.2.0 (carp) is up.
DEBUG:openflow.of_01:Listening on 10.0.1.8:6633
INFO:openflow.of_01:[70-b3-d5-00-00-00 1] connected
Zodiac_FX(openflow)# show status
 Status: Connected
 Version: 1.0 (0x01)
 No tables: 1
 No flows: 0
 Table Lookups: 0
 Table Matches: 0

You can then load POX programs to manuipulate the network. A popular first choice might be to turn the Zodiac FX into a flooding hub.

debian:~ $ ./pox.py --verbose openflow.of_01 --address=10.0.1.8 --port=6633 forwarding.hub
POX 0.2.0 (carp) / Copyright 2011-2013 James McCauley, et al.
INFO:forwarding.hub:Hub running.
DEBUG:core:POX 0.2.0 (carp) going up...
DEBUG:core:Running on CPython (2.7.9/Mar 8 2015 00:52:26)
DEBUG:core:Platform is Linux-4.1.19-v7+-armv7l-with-debian-8.0
INFO:core:POX 0.2.0 (carp) is up.
DEBUG:openflow.of_01:Listening on 10.0.1.8:6633
INFO:openflow.of_01:[70-b3-d5-00-00-00 1] connected
INFO:forwarding.hub:Hubifying 70-b3-d5-00-00-00
Zodiac_FX(openflow)# show flows
Flow 1
 Match:
  Incoming Port: 0			Ethernet Type: 0x0000
  Source MAC: 00:00:00:00:00:00		Destination MAC: 00:00:00:00:00:00
  VLAN ID: 0				VLAN Priority: 0x0
  IP Protocol: 0			IP ToS Bits: 0x00
  TCP Source Address: 0.0.0.0
  TCP Destination Address: 0.0.0.0
  TCP/UDP Source Port: 0		TCP/UDP Destination Port: 0
  Wildcards: 0x0010001f			Cookie: 0x0
 Attributes:
  Priority: 32768			Duration: 9 secs
  Hard Timeout: 0 secs			Idle Timeout: 0 secs
  Byte Count: 0			Packet Count: 0
 Actions:
  Action 1:
   Output: FLOOD

If we now send a packet into Port 1 we see it flooded to Port 2 and Port 3.

We also see it flooded to Port 4 (which is in 'native' mode). Flooding the packet up the same port as the OpenFlow controller isn't a great design choice. It would be better if the switch had four possible modes for ports with traffic kept distinct between them: native switch forwarding, OpenFlow forwarding, OpenFlow control, and switch management. The strict separation of forwarding, control and management is one of the benefits of software defined networks (that does lead to questions around how to bootstrap a remote switch, but the Zodiac FX isn't the class of equipment where that is a realistic issue).

VLANs between ports only seem to matter for native mode. A OpenFlow program can — and will — happily ignore the port's VLAN assignment.

The Zodiac FX is currently a OpenFlow 1.0 switch. So it can currently manipulate MAC addresses but not other packet headers. That still gives a suprising number of applications. Northbound Networks say OpenFlow 1.3 -- with it's manipulation of IP addresses -- is imminent.

The Zodiac FX is an interesting bit of kit. It is well worth buying one even at this early stage of development because it is much better at getting your hands dirty (and thus learn) than is the case with software-only simulated OpenFlow networks.

The source code is open source. It is on Github in some Atmel programming workbench format [Errata: these were some Microsoft Visual Studio 'solution' files]. I suppose it's time to unpack that, see if there's a free software Atmel toolchain, and set about fixing this port mode bug. I do hope simple modification of the switch's software is possible: a switch to teach people OpenFlow is great; a switch to teach people embedded network programming would be magnificent.

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:

Pin

Name

Description (direction)

1

CTS

Clear to send (output)

2

DTR

Data terminal ready (output)

3

TxD

Transmit data (output)

4

Gnd

Signal ground

5

Gnd

Signal ground

6

RxD

Receive data (input)

7

DSR

Data set ready (input)

8

RTS

Request to send (input)

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:

Pin

Name

Description (direction)

1

DCD

Data carrier detect (input)

2

RxD

Receive data (input)

3

TxD

Transmit data (output)

4

DTR

Data terminal ready (output)

5

Gnd

Signal ground

6

DSR

Data set ready (input)

7

RTS

Request to send (output)

8

CTS

Clear to send (input)

9

RI

Ring indicator (input)

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).

I have written before about the naming of network items, but someone asked for a summary.

You carve out a part of DNS as yours, and .net.example.edu.au is a good choice as that prevents name clashes with "user-visible" DNS names. You name devices within that with no further DNS hierarchy. Obviously we do need some hierarchy, we simply don't use DNS dots to do it as they are elided by almost all network management systems.

I strongly recommend a geographical-then-function-then-counter naming system. Sort of like b4-f1-sw2 for the management interface of Building #4, Floor 1, switch 2. But you'll need to adjust the basic outline so it works well for your local circumstances. Do not put the make and model in the name, upgrading a switch should be cheap and simple, so the less to change the better. Try to avoid using L or O or I next to digits. Names are in lower case only.

For the non-management interfaces DNS hierarchy is a good idea. Take VLAN4 of eth0 of the router b4-f1-r1, that would get the DNS name vlan4.eth0.b4-f1-r1.net.example.edu.au. Use the vendor's name for the interface, so if they call it GigabitEthernet0 then you say vlan4.gigabitethernet0.b4-f1-r1.net.example.edu.au and if they call it ge-0/0/0 then you say vlan4.ge-0-0-0.b4-f1-r1.net.example.edu.au. But do use your own names for the subinterface technology as this rapidly brings errors to the fore, "vlan4", "isl4", "lane4", "mpls0", "gre0", and so on. Use the same names for IPv4 and IPv6.

Sometimes you'll provide the IP address for use by someone else. Name these gateways links with additional hierarchy: both the customer identifier (an order number, or customer ID, or ASN for a peering link) and a counter. If you are doing split service delivery (unicast here, multicast there) then note that in the naming too. Typically gw1.cust1234.vlan4.eth0.b4-f1-r1.net.example.edu.au, but a worst case could be as ugly as gw1.multicast.ipv6.as666.vlan4.eth0.b4-f1-r1.net.example.edu.au.

Accessing your management interfaces

You can, and should, place management access in a VLAN away from users. In a small network there is no need to route that VLAN. Instead drop a couple of bastion servers on the management LAN. Connect those servers to your non-management network and give those servers plenty of backdoor connectivity: PSTN modems attached to a POTS phone line, GSM modems, ADSL service. Set up a SSH CA and use that to control SSH access. Run your standard authentication, but put a replica of the authentication on each of the bastions (maybe subsetting that if you have a lot of users). That way the bastion users are running the corporate password policy but network engineers are able to log in when the only device in the entire network which is reachable is the bastion server (via one of its backdoor links). Also have those servers run a lot of VPN options: the typical network engineer workstation can simply bring up that VPN rather than SSH through the bastion. The network management platforms can be on the "real" network, getting the benefits of easy administration (eg, puppet) whilst running VPN tunnels to all of the bastion server to query the management interfaces of the networking devices.

Run one bastion server per network core. Remember that these servers need not be large, a low power 1RU server with a couple of ethernet interfaces is overkill). You might need a USB hub to be able to plug in all of the PSTN, GSM and ADSL modems. If you have new switches with USB consoles then plug them into the hub as well. If you have the older RS-232 consoles then plug them into a 8 or 16 port RS-232/USB concentrator.

You can buy "console servers" commercially, and they are worth a look. Usually they fail as bastion servers as they can't replicate the corporate authentication database and don't run a range of VPN choices. In a big datacentre use a console server and plug it into the management VLAN and use the bastion server to reach it. Some console servers have two management interfaces, and one can run directly to the bastion server.

After doing all of this good work, make sure the system administrators don't do an end-run around it. Their KVM switches go onto the management network, as do their ILMI interfaces. As the number of hosts on this network can get large do try to run IPv6-only whereever possible (just doing that for the ILMI interfaces can save a lot of IPv4 addressing). Furthermore, using IPv6's autoconf is much more resilient to networking issues than IPv4's DHCP. You should use static addressing on major assets and obviously on routers. Closet switches and the like should all use DHCP to obtain their address (even if you statically assign the addressing back at the DHCP server) because the aim there is to drive the administration overhead to the floor.

Ignore people who tell you to use NAT for the management VLAN. One day you'll find yourself on a router with no VRFs where you want to suppress all private networks whilst trying to keep the range you need for management connectivity. You will then hunt that person down and kill them. With a spoon, because it is more painful.

Use a iptables rule to set DSCP = CS6 (control) for ssh as packets exit out of the bastion server into the management network. Set them back to DSCP = BE as they exit out of the bastion server into the customer network (otherwise they'll get policed by the router). Also set that DSCP on the devices in the management network ("ip ssh dscp 48"). Resist the temptation to set DSCP for SNMP, as it can be like a bulk data transfer at times. Use the same QoS design in the management network as you do for the customer network.

Some auditors don't like the network management names appearing in DNS. In that case run a DNS forwarder on the bastion servers. Set that forwarder up to look in the zones for .net.example.edu.au and the reverse zone for the IP addressing, then to forward other zones. Or you can use dnsmasq to do the same with a hosts file. Using dnsmasq has the advantage that you can suppress the DNS names of the router's forwarding interfaces too. Obviously the network elements point to the DNS forwarder at their nearest core. When people connect using the VPN then it can replace their laptop's DNS resolver list and then they'll automatically see the verboten names. But really, getting better auditors is the correct answer, because making your network more difficult to diagnose is to increase the risks to the business, not to decrease them.

Tip

Typing:

$ ssh b4-f1-sw2.net.example.edu.au

can be painful. Especially from a corporate laptop where you can't change the DNS search list. Use a SSH ~/.ssh/config file to do the expansion:

Host *-*-*
  Hostname %h.net.example.edu.au

Ask the systems' administrators to set up a ssh CA and generate keys for devices. That's easy to do when starting out, and a major pain to do afterwards.

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 = mtuicmpv4_headeripv4_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 = mtuicmpv6_echo_headericmpv6_headeripv6_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 …

The network time protocol has been used as traffic multipliers in denial of service attacks. This article looks at the choices in distributing time throughout a campus network.

Anti-spoofing. Interfaces connect to routers or to hosts, not to both. Do anti-spoofing for each host-facing subnet. At your border reject packets with your network in the source address, you can do that through routing plus anti-spoofing, or through a ACL.

Use application firewalls in your DMZ. NTP, DNS, SIP, H.323. Don't send all traffic through your general-purpose firewall as it can add less value (for example, it can't check DNSSEC responses for validity).

NTP

Run a GPS-based time server. GPS is run by the US Air Force and is closely monitored, so it's accuracy is understood. This will require an external antenna on the building with good views to the horizons and arranging this is usually the most difficult part of the exercise.

You need three additional servers, so that they can vote down your misbehaving GPS receiver. For security reasons those servers should be outside the GPS receiver's horizon, so that a local RF-based attack doesn't succeed against the remote servers too.

Internally run at least two NTP servers in your interior-facing DMZ, peered together. These are the ones your hosts are configured to use.

If you run multicast, block NTP multicast at the edge. Provide your own NTP on that multicast address within the interior.

On the firewall block all NTP, in and out. An interior host should only be able to reference the official servers within the site. An exterior host should not be able to reach a host which is unknowingly providing a NTP service.

DNS

H.323, SIP and QoS

These also control access to the Voice and Video QoS classes, so on the firewall reset other users of those DSCPs Users should be able to set two QoS classes: best effort and scavenger. Other QoS use should go via a application proxy to be validated.

Reset incoming DSCP to addresses other than the voice and video gateways.

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.

Tools

2013-06-10 17:42

Tools for electronics can be hard to find. So when I visited Sim Lim Square in Singapore I picked up a few of the harder-to-find tools, such as a range of tweezers. I was an idiot, because today I went to the Adelaide Model Train Exhibition and some of the exhibitors there had just the nicest stuff for handling small objects. The prices were roughly the same as in Singapore but the quality was much better.

A revelation to me was Burfitt Tools of Western Australia. They make a range of the most wonderful small item pliers: pointed enough to get in and hefty enough to apply some power when there. They also make a massive range of tweezers, clamps, drivers, taps and even a tiny hammer. When I asked if they did the "internet shopping thing" two people in the line behind me said that they did and were good to deal with.

Also there was Aztronics, the wonderful Adelaide electronics shop.

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.

There are two useful, but unsupported, commands in Cisco IOS.

The first is a configuration to allow SFPs that do not pass IOS's check for Cisco SFPs.

Router(config)# service unsupported-transceiver
Router(config)# no errdisable detect cause gbic-invalid
Router(config)# errdisable recovery cause gbic-invalid
Router(config)# no errdisable detect cause sfp-config-mismatch
Router(config)# errdisable recovery cause sfp-config-mismatch

In a large environment it is worthwhile setting this even if using the manufacturer's SFPs.

The second is a command to run ttcp ("test TCP"). ttcp is also available for Unix and Windows. So you can test for TCP performance hop-by-hop through the network. ttcp is a more useful acceptance test for provisioned bandwidth and reliability for new links than ping.

Router# ttcp
transmit or receive [receive]:
perform tcp half close [n]:
receive buflen [8192]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
rcvwndsize [0]:
ack frequency [2]:
delayed ACK [y]:
show tcp information at end [n]: y

Remember that Cisco IOS doesn't have swap. So although receive buflen should be set to the path's bandwidth-delay product, beware that if the TCP buffer is larger than available memory then the router will reboot. The router's available memory can be queried with show process memory.

By the way, ping has some use for link acceptance testing. You can use it to query the MTU of the link by setting the Don't Fragment bit. You can also fill a large packet with all zero bits and all one bits, which can uncover clocking issues.

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 bits1 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.

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

MPLS is a nice technology. It allows the network topology to be altered using tunnels, but without the drama of IP in IP tunnels. MPLS can be used to solve some otherwise tricky network engineering problems, such as excluding some classes of customer from some links.

But then people had to apply MPLS to virtual private networks. VPLS is a design disaster, routers simply shouldn't be holding MAC tables and the entire technology has the feel of using a sledgehammer to crack a nut.

Provider Backbone Transport looks like a much better approach to implementing VPNs. Basically a VPN is a VLAN for that customer. Of course if you do that with ethernet switches (as do many metro networks) you quickly find out that Ethernet is a poor carrier protocol. PBT strips from Ethernet all the qualities which make it a poor carrier protocol and adds carrier fault management.

Best of all, there is a proposal to use GMPLS to provision the PBT service. The ease of service provisioning is one of the real advances of MPLS, so it is nice to see this retained.

Using Generalised MPLS is a good idea, as this allows a path to cross technologies, so customer links can cross the routed backbone (presumably in a VPN QoS class).

Notes on PBT

Transparent Ethernet bridging without flooding or learning. Topology if pre-configured, as is a fast-reroute path. 802.1Qah describes the Ethernet encapsulation.

A whole heap of standards for diagnosis.

  • 802.3ah Ethernet in the First Mile describes the customer-facing port and its OAM.

  • 802.1ag Ethernet connectivity fault management.

  • ITU-T Y.1731 gives fault management and SLA monitoring.

The fast re-route path is activated by ITU-T G.8031 Ethernet Protection Switching.

A ID for GMPLS to create the topology for the main and fast re-route path. This will eventually need IS-IS-TE to discover the topology.

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.

Computer memory has a life. It starts expensive, then gradually drops in price over the years until it is ridiculously cheap, then it is superceeded. In in few years time if you try to buy the superceeded memory then it is outrageously expensive.

Which brings me to 2GB flash memory. If you have an older camera -- particularly one that understands SD flash but not SDHC flash -- then the most it can take is a 2GB card. Those cards are ridiculously cheap at the moment -- $15 for a cheapo standard-speed card, $25 for a brand-name high-speed card. Now is the time to upgrade that puny 16MB SD card that came with the camera to the maximal 2GB card. Prices are so low that you can buy a fast flash card for double the price, and this seems to remove a lot of the sluggishness out of the older camera I own.

SD: "Secure digital".
SDHC: "Secure digital, high capacity".

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.

I like to teach computing. Some demo kit is useful. Those old 5.25in hard disks are big enough to show people what a splindle, cylinder and track actually are. It's easy to see that moving the disk head is going to take a lot of time.

When teaching networking an old hub is useful. Every port see every bit, so it's easy to drop Wireshark into the middle of a connection and have it decode the protocols. Also useful for teaching networking is some old thinnet coax with AUIs and drops -- nothing shows quite so clearly why we moved to structured cabling and hubs.

I show people an old 1RU hub. Most people have no idea what professional networking equipment looks like.

Also useful is dynamips and dynagen, emulators for the Cisco 7200 hardware, a classic router. You need to know how Cisco IOS works, and dynamips is a painless way to built a small network and get that experience. Juniper has olive, which does something similar and is well worth a look by those familiar with IOS just to see another take on what a router command line should look like. If Juniper has any sense it will release Olive formally, since people's fear of their different (but far superior) configuration technique is one of the factors limiting Juniper's penetration into non-ISP businesses.

If people have a stack of old USB floopy drives around I'd love to scarf four of those. Nothing would show more clearly how the various RAIDs work.

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.

After a long time we finally have a study on the carbon life cycle cost of modern photovoltaic cells: Fthenakis, Kim, Alsema. Emissions from Photovoltaic Life Cycles. ASAP Environmental Science and Technology, 10.1021.

The bottom line is that PV cells are 11% of the carbon cost of natural gas electricty generation, the cleanest of the fossil fuels. The estimate is that PV cells are 90-100 times better than coal-fired electricity generation (the predominant form of generation in Australia).

The study also assumes that PV cells replace generators in-situ. That is, the results don't include the savings in the reduced size of the electricty grid from having PV cells at the point of power usage (eg, on a house roof). About 30% of electircity is lost in transmission through the grid.

None of this would be surprising except for the FUD from the flat earth brigade that PV cells had a massive carbon footprint from their manufacturing process that was so large it dominated later power generation. The paper shows that this assertion is incorrect.

All in all, it looks like a home PV system has about 1000 times less carbon footprint than South Australian grid electricity.

This isn't to say that all is sweetness and light with PV solar. Most systems still use the grid, and that's a major source of inefficiency and possibly unnecessary investment. The PV gains need to be discounted by a share of the cost of the grid power. At the time time, off-grid is problematic as there is no good metropolitan home electricity storage system that doesn't have a large environmental impact from the chemicals used.

What we need is some of the promising storage systems (such as hot salt) to scale down to domestic application. That's difficult whilst they use exotic technology such as high-temperature pumps.

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.

Routers are addressed differently to hosts. Here's how to do it.

Router's have a control address, a IPv4 /32 and a IPv6 /128. Allocate an address range for these at the top of your address allocation. Make the range easily expressible in an access list.

Configure this control plane address on the major loopback interface:

interface Loopback0
 ip address 10.1.255.1 255.255.255.255
 no ip redirects
 no ip proxy-arp
 ipv6 enable
 ipv6 address 1020:3040:ffff::1/128
 no ipv6 redirects
 ipv6 ospf 64000 area 0.0.0.0
 ip pim sparse-mode
 ip sap listen

router ospf 64000
 network 10.1.255.1 0.0.0.0

This address is the control plane address for routing updates:

router ospf 64000
 router-id 10.1.255.1

ipv6 router ospf 64000
 router-id 10.1.255.1

ip msdp peer ...  connect-source Loopback0 remote-as 64000

router bgp 64000
 router-id 10.1.255.1
 neighbor IBGP-PEER4 peer-group
 neighbor IBGP-PEER4 remote-as 64000
 neighbor IBGP-PEER4 description iBGP links to other routers in my AS
 neighbor IBGP-PEER4 password ...
 neighbor IBGP-PEER4 update-source Loopback0
 neighbor IBGP-PEER6 peer-group
 neighbor IBGP-PEER6 remote-as 64000
 neighbor IBGP-PEER6 description iBGP links to other routers in my AS
 neighbor IBGP-PEER6 password ...
 neighbor IBGP-PEER6 update-source Loopback0
 address-family ipv4 unicast
  neighbor IBGP-PEER4 activate
  neighbor IBGP-PEER4 send-community
  no neighbor IBGP-PEER6 activate
  no synchronization
  no auto-summary
 exit-address-family
 address-family ipv4 multicast
  neighbor IBGP-PEER4 activate
  neighbor IBGP-PEER4 send-community
  no neighbor IBGP-PEER6 activate
  no auto-summary
 exit-address-family
 address-family ipv6 unicast
  no neighbor IBGP-PEER4 activate
  neighbor IBGP-PEER6 activate
  neighbor IBGP-PEER6 send-community
  no synchronization
 exit-address-family
 address-family ipv6 multicast
  no neighbor IBGP-PEER4 activate
  neighbor IBGP-PEER6 activate
  neighbor IBGP-PEER6 send-community
 exit-address-family

If you do not have a distinct management plane, use the control plane address for management activities:

ip ftp source-interface Loopback0
ip flow-export source Loopback0
ip tacacs source-interface Loopback0
logging source-interface Loopback0
snmp-server trap-source Loopback0
ntp source Loopback0
ip telnet source-interface Loopback0
ip tftp source-interface Loopback0
ip radius source-interface Loopback0

ip access-list standard VTY-LIST4
 permit 10.1.255.0 0.0.0.255

ipv6 access-list standard VTY-LIST6
 permit 1020:3040:ffff::1/64

line vty 0 4
 location Network
 transport preferred none
 transport intput ssh
 transport output ssh telnet
 access-class VTY-LIST4 in
 ipv6 access-class VTY-LIST6 in

The loopback interface holds the name of the router. Routers are named so that they are fully-described in the left-hand part of their DNS name. This is because many network management applications only display the first part of the domain name.

The name should be short (you'll be typing it a lot), specify the location, a location counter, the equipment and an equipment counter. Depending on your philosophy the equipment is specified using a general purpose identifier (such as "co" for a core router) or a make/model (such as c7200 or m40).

The name should be placed in a part of the DNS not used for any other purpose. So the top level of example.edu.au is not a good idea, net.example.edu.au is much better.

interface Loopback0
 description adl1-co1
$ORIGIN net.example.edu.au.
adl1-co1 IN AAAA 1020:3040:ffff::1
adl1-co1 IN A 10.1.255.1

Forwarding plane interfaces are named after the interface.

interface GigabitEthernet0
 description Building 23 (fiber path F-ASSD-01-03)
 ip address 10.1.4.255 255.255.255.0
 ipv6 address 1020:3040:0004:/64 eui-64

router ospf 64000
 passive-interface GigabitEthernet0

ipv6 router ospf 64000
 passive-interface GigabitEthernet0

Router-router links should use ::1/64 and ::2/64 and have a OSPF network type of point-to-point (router election is now the major delay in OSPF). Router-host links should use EUI-64 and disable OSPF.

The name for this interface will be:

$ORIGIN net.example.edu.au.
gi0.adl1-co1 IN A 10.1.4.255
gi0.adl1-co1 IN AAAA 1020:3040:0004:...

You can help users help themsleves by expanding the necessarily obscure router name; after all, you are never going to type this:

$ORIGIN net.example.edu.au.
gi0.core-1.pop-1.adelaide IN A 10.1.4.255
gi0.core-1.pop-1.adelaide IN AAAA 1020:3040:0004:...

VLANs and logical subnets simply get added in front of the interface name. Make debugging simpler by using the name to distinguish the technology used: so "vlan90" for 802.1Q, "isl90" for Cisco ISL, "lane90" for ATM, "vpls90" for MPLS and so on rather than giving all of these ethernet-like services an annodyne "vlan" name.

Page generated 2017-06-27 14:01
Powered by Dreamwidth Studios