Cisco Configuration Cheat Sheet - Part 1

I'm teaching CIS-81 Fundamentals of Networking next semester (with the great Rick Graziani). The class is taught using Cisco equipment. Until this summer I've never touched a piece of Cisco hardware in my life. What an eye opener! The CLI is very strange and primitive compared to Linux. But it's a CLI, therefor I like it.

I've been using Packet Tracer (AMAZING!) to do my labs and it's really incredibly fun. So here are the first tasks I do when setting up a network. The network is pictured on the left.

I'm going to start by configuring the router. I don't use the default configuration dialog because I want to do everything myself.

// Step 0: Basics 
> enable
# config t 
(config)# hostname ginsu
(config)# ip domain name lifealgorithmic.com // Need for SSH
(config)# banner login \

(config)# banner motd \

// Step 1: Security 

// Set the "enable" password. Never use enable password!
(config)# enable secret cisco 

// Set the password to login to the console
(config)# username cisco secret cisco 
(config)# line console 0 

(config-line)# login local
(config-line)# logging synchronous // I don't actually like this

// Make sure the login password is "encrypted"
(config)# service password-encryption

// Enable SSH (and disable evil Telnet)
(config)# crypto key generate rsa 
(config)# line vty 0 15
(config-line)# transport input ssh

(config-line)# login local

// Step 2: Interfaces (on the Router)
(config)# interface GigabitEthernet 0/1

(config-if)# ip address 10.0.0.1 255.0.0.0

(config-if)# ipv6 address 2001:db8:fade:1::1/64

(config-if)# ipv6 address fe80::1 link-local

(config-if)# description MyInterface

(config-if)# no shutdown

// Step 3: Management Interface (on the Switch)
(config)# interface Vlan 1

(config-if)# ip address 10.0.0.2 255.0.0.0

(config-if)# ipv6 address 2001:db8:fade:1::2/64

(config-if)# no shutdown

// Step 4: Configure DHCP on the router

(config)# ip dhcp excluded-address 10.0.0.1

(config)# ip dhcp excluded-address 10.0.0.2

(config)# ip dhcp pool mynet

(dhcp-config)# default-router 10.0.0.1

(dhcp-config)# dns-server 8.8.8.8

(dhcp-config)# network 10.0.0.0 255.0.0.0

// Step 5: Make it stick

# copy running-config startup-config

# reload

Can you spot the differences?

Of course you never go into production on revision A. Lesson learned: Never use autosensing level shifters for transmission applications. They just don't have enough drive strength for a long wire. They have a very counterintuitive property when they're driving a load that's too big: they go into oscillation. When the driver cannot bring the output level above threshold before the one-shot timeout it will switch directions. Then it will try to overwhelm the driver on the Teensy (it can't) and switch directions again. Repeat.

I also had to pick different capacitors for C1 and C5. The ones I had were to big to fit into the tube. The new ones have smaller values and less voltage margin. I really hope I get away with that.

There's one more thing different. Can you spot it?

New Candle Controller

Of course, as soon as you find a use for a board you figure out what's wrong with it. The candle controller is going to be used on my Burning Man project this year but needs to fit into a smaller tube. So a quick re-layout and ta-da. The narrow board. I never tested XBee on the first candle. I really hope it works.

Six Degrees of Bacon!

This programming assignment, Six Degrees of  Bacon, by Steve Hodges has inspired me for the last two weeks. So on my first day off (yes, really) I have forgone food and a shower to make this homage.

The code is on GitHub: https://github.com/mike-matera/Six-Degrees

The Candle is Here!

It's Here

Setup

It's a fun day when you receive the first copy of a new circuit board. What did you forget to order? Are all the parts right? No. They never are. So here's what I missed:

1. Forgot to order my 3.3v regulators 
2. Forgot to order my 22k resistors
3. Ordered the level translator in the TSSOP instead of the SOIC package

There's a little silk screen error that's different between my gerbers and what the fab made. It cutoff the name of my website! Oh no. I'm getting everything ready for assembly. Now I just have to figure out how I'm going to use the wireless connectivity. 

Candle Controller

My prototype digital candle looked really good. The prototype used a separate power board wired to the Teensy3.0. That was cost effective but cost a lot of labor and delicate soldering to complete. This new board swallows the Teensy and incorporates the power supply. Better still it has a slot to swallow an XBee. That means this board will be able to communicate with the outside world. I'm not sure what I'm going to do with that just yet. I'll think of something.

Benchmarks

I got Cznic's code to work with very little trouble. I spent much more time thinking about how to make benchmark results comparable. The issues I considered are:

1. The trees must be of the same order (I used 128)
2. The trees must use the same key type (I used uint64)
3. The trees must be pre-filled with a large number of elements

Let me take a moment to explain #3. The benchmarking engine in Go works by calling your code with an iteration count. It times your code and then divides the time by the count to determine the number of nanoseconds per iteration. It starts with a small iteration count and increases the value until the sample is statistically valid. This has a poor property for comparing b-trees: The more elements in the tree the slower most operations will proceed. I can't control the iteration counts, instead I pre-filled the trees with 4 million elements. Why 4 million elements? Because inserting another million elements is not likely to change depth of the tree. 

The results of the benchmark:

BenchmarkRandomPut  200000      11836 ns/op
BenchmarkCznicRandomPut   1000000       1556 ns/op
BenchmarkRandomGet 5000000        652 ns/op
BenchmarkCznicRandomGet   2000000        797 ns/op
BenchmarkRandomDelete   200000      12581 ns/op
BenchmarkCznicRandomDelete 1000000 1228 ns/op

There's clearly a severe penalty for the Load() and Store() operations making my implementation an order of magnitude slower for operations that alter the tree. The good news is that my fetch implementation is somewhat faster. Since the expected mix of operations on a b-tree heavily favors lookups I believe that this offsets my poor update performance somewhat. 

How do I know that Load() and Store() eat up a lot of time? Go has a built-in profiling tool. Here's how it works. First you add some profiling code to a test harness. This is what I did:

file, _ := os.Create("insertions.out")

pprof.StartCPUProfile(file)

for i:=0; i<5000000; i++ {

tree.Put(uint64(src.Int63()), i)

}

pprof.StopCPUProfile()

You can then open your profile result (insertions.out) like this:

$ go tool pprof bin/main insertions.out

Welcome to pprof!  For help, type 'help'.

(pprof) 

In this case "bin/main" is the name of my executable. Much more information on how to use Go's pprof can be found here. The first command you're likely to use is the "top" command which shows you your top 10 CPU users. 

(pprof) top

Total: 5291 samples

    1289  24.4%  24.4%     2563  48.4% github.com/mike-matera/Go/btree.(*SimpleNode).Store

    1069  20.2%  44.6%     1069  20.2% github.com/mike-matera/Go/btree.(*SimpleNode).Load

     272   5.1%  49.7%      285   5.4% github.com/mike-matera/Go/btree.(*SimpleNode).Find

     240   4.5%  54.2%      809  15.3% runtime.assertE2T

     233   4.4%  58.6%      233   4.4% runtime.memcopy64

     209   4.0%  62.6%      584  11.0% assertE2Tret

     200   3.8%  66.4%      433   8.2% copyout

     196   3.7%  70.1%      344   6.5% sweepspan

     195   3.7%  73.8%      195   3.7% flushptrbuf

     141   2.7%  76.4%      344   6.5% scanblock

You can see that the top CPU hogs were Store() and Load(). The right most percentage is the percent of samples where those functions were on the call stack. A whopping 68.6% of the time. The 'web' command creates a nice SVG image of the result. Below are the results of the loop above and a similar one that fetches values.

Insertions Profile

Fetches Profile