Posts on network-notes

CLI Over HTTPS Part 2: Proving It

brett@network-notes.com (Brett Lykins) — Thu, 30 Apr 2026 09:00:00 +0000

In Part 1, I argued that SSH is a slow transport for network automation at scale and that HTTPS is fundamentally faster. Round-trip analysis and back-of-napkin math are useful, but they’re not proof. This post is the proof.

I built clibench, a dual-protocol network device emulator and benchmark client that measures the difference at realistic latencies sourced from Verizon’s published backbone measurements.

Design Constraints

For the comparison to mean anything, the test has to be fair. That means:

Same device, same commands, same output. Both transports hit the same device.Device struct. The only variable is how the command arrives and how the response leaves.
Same latency for both. Delay is injected at the TCP connection level, not the application level. Both SSH and HTTPS experience identical network conditions.
Realistic latency values. No made-up numbers. Every profile is sourced from published measurements.
Multiple modes per transport. SSH gets tested with fresh connections and with connection reuse (ControlMaster-style). HTTPS gets tested with fresh connections, keep-alive, multi-command batching, and config push. Each mode represents a real-world usage pattern.

Architecture

clibench is written in Go. The project has nine packages:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


internal/
 bench/ Benchmark runner: SSH, HTTPS, proxy, and PTY modes
 device/ Shared command engine: prefix matching, transcript loading
 sshserver/ crypto/ssh listener, CiSSHGo patterns
 httpserver/ net/http + TLS, ASA-style /admin/exec/ and /admin/config
 proxy/ HTTPS→SSH edge proxy (fresh + pooled modes)
 netem/ tc netem latency injection (Linux, requires sudo)
 latency/ Userspace delay injection (fallback, no root)
 stats/ Benchmark statistics: percentile, summarize, parallel runner
 tlsutil/ Shared self-signed TLS config generator

The benchmark client embeds its own server. No separate process needed. Latency is injected at the kernel level using Linux tc netem, applied per-port on the loopback interface so both SSH and HTTPS experience identical network conditions.

The Shared Command Engine

Both servers use the same device.Device:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


type Device struct {
 Hostname string
 Username string
 Password string
 commands map[string]string // "show version" -> transcript text
 transcriptDir string
}

func (d *Device) Exec(input string) string {
 input = strings.TrimSpace(input)
 if input == "" {
 return ""
 }
 // exact match first
 if resp, ok := d.commands[input]; ok {
 return resp
 }
 // prefix match ("sh ver" -> "show version")
 // returns "% Ambiguous command" or "% Unknown command" on miss
}

Command transcripts are plain text files loaded from a directory. The filename convention maps to the command: show_version.txt becomes show version. Templates support {{.Hostname}} substitution. This follows the same pattern as CiSSHGo, which I wrote about recently.

The SSH Server

The SSH side uses Go’s crypto/ssh package with an ed25519 host key generated at startup. It supports both exec mode (ssh host "show version") and interactive shell sessions with prompt rendering and command matching. The benchmark client tests both, since real-world tools are split: libraries like Go’s x/crypto/ssh use exec mode, while Netmiko, Ansible, and Scrapli use PTY/shell.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// Exec mode: split newline-delimited payloads for batch support
case "exec":
 if len(req.Payload) > 4 {
 execCmd = string(req.Payload[4:])
 }
 req.Reply(true, nil)
 if execCmd != "" {
 var out strings.Builder
 for _, line := range strings.Split(execCmd, "\n") {
 cmd := strings.TrimSpace(line)
 if cmd != "" {
 out.WriteString(s.dev.Exec(cmd))
 }
 }
 io.WriteString(ch, out.String())
 }
 ch.SendRequest("exit-status", false, []byte{0, 0, 0, 0})

The HTTPS Server

The HTTPS side generates a self-signed P-256 ECDSA certificate at startup (negotiating TLS 1.3 with TLS_AES_128_GCM_SHA256) and exposes the same endpoints as the Cisco ASA HTTP interface:

GET /admin/exec/show+version. Single command, URL-encoded
GET /admin/exec/cmd1/cmd2/cmd3. Multiple commands, slash-separated
POST /admin/config. Bulk commands, newline-delimited body

Authentication is HTTP Basic over TLS, matching the ASA’s behavior.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


func (s *Server) handleExec(w http.ResponseWriter, r *http.Request) {
 path := strings.TrimPrefix(r.URL.Path, "/admin/exec/")
 parts := strings.Split(path, "/")
 var out strings.Builder
 for _, p := range parts {
 cmd := strings.ReplaceAll(p, "+", " ")
 cmd = strings.TrimSpace(cmd)
 if cmd == "" {
 continue
 }
 out.WriteString(s.dev.Exec(cmd))
 }
 w.Header().Set("Content-Type", "text/plain")
 io.WriteString(w, out.String())
}

The Benchmark Client

The client calls both transports with the same commands and measures wall-clock time. The key difference is visible in the code: SSH requires connection setup, auth, channel open, and per-command exec requests. HTTPS is a single HTTP call:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// SSH: connect + auth + exec per command
client, _ := ssh.Dial("tcp", addr, sshConfig)
for _, cmd := range commands {
 session, _ := client.NewSession()
 output, _ := session.CombinedOutput(cmd)
 session.Close()
}

// HTTPS: one request, all commands
url := "https://" + addr + "/admin/exec/" + strings.Join(commands, "/")
resp, _ := httpClient.Get(url)
body, _ := io.ReadAll(resp.Body)

Latency Injection

Latency is injected using Linux tc netem on the loopback interface, configured entirely via the vishvananda/netlink library, the same netlink library used by Docker and Kubernetes. The tool sets up a prio qdisc with per-port u32 filters so that traffic to the SSH and HTTPS server ports gets the configured one-way delay, while other loopback traffic is unaffected. This requires root or CAP_NET_ADMIN, the same requirement as most raw-socket networking tools.

Netlink qdisc setup code (click to expand)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


// Qdisc setup via netlink - no shell-out to tc
prio := netlink.NewPrio(netlink.QdiscAttrs{
 LinkIndex: loopbackIndex,
 Handle: netlink.MakeHandle(1, 0),
 Parent: netlink.HANDLE_ROOT,
})
prio.Bands = 4
prio.PriorityMap = [16]uint8{} // unmatched traffic → band 0 (no delay)
netlink.QdiscAdd(prio)

netem := netlink.NewNetem(
 netlink.QdiscAttrs{Parent: netlink.MakeHandle(1, 2)},
 netlink.NetemQdiscAttrs{Latency: uint32(delay.Microseconds())},
)
netlink.QdiscAdd(netem)

// Per-port u32 filter: match dport, classify to delayed band
netlink.FilterAdd(&netlink.U32{
 FilterAttrs: netlink.FilterAttrs{Parent: netlink.MakeHandle(1, 0), Protocol: 0x0800},
 ClassId: netlink.MakeHandle(1, 2),
 Sel: &netlink.TcU32Sel{
 Flags: netlink.TC_U32_TERMINAL,
 Keys: []netlink.TcU32Key{{Val: uint32(port), Mask: 0xffff, Off: 20}},
 },
})

Because netem operates at the kernel’s network stack, it captures real TCP behavior: Nagle’s algorithm, delayed ACKs, TCP window scaling, and proper per-packet delay. Every packet in both directions, client-to-server and server-to-client, experiences the configured delay. This is more accurate than userspace delay injection, which can’t distinguish between logically separate protocol exchanges that happen to be coalesced into a single write.

A -userspace flag is available as a fallback for environments where root isn’t available, but the published numbers all use tc netem.

Latency Profiles

Each profile corresponds to a real network path, sourced from Verizon Enterprise’s monthly IP latency statistics (March 2026). The simulated RTT values are rounded for readability; the Verizon measured column shows the exact source data:

Profile	Simulated RTT	Real-world path	Verizon measured RTT
`local`	0ms	Co-located	Baseline
`campus`	2ms	Same data center	AWS/Prisma: 1-2ms
`regional`	30ms	US backbone	29.9ms
`continental`	70ms	NYC ↔ London	70.2ms
`intercontinental`	150ms	US ↔ Hong Kong	145.5ms
`transpacific`	175ms	NA ↔ Taiwan	175.2ms

Benchmark Modes

The client tests these scenarios across both transports (plus a multi-command GET mode when running more than one command per iteration):

SSH Exec Modes

SSH exec mode opens a channel, sends a command, and reads the output. This is what Go’s x/crypto/ssh, Paramiko’s exec_command(), and OpenSSH’s ssh host "cmd" use. Each command gets its own channel.

Mode	What it measures
`ssh/fresh-conn`	Full SSH lifecycle per iteration: TCP + handshake + auth + channel + exec
`ssh/reuse-conn`	One SSH connection shared across all iterations (ControlMaster-style)
`ssh/batch-exec`	Multi-line command string over a single exec session

SSH PTY/Shell Modes

SSH PTY mode opens an interactive shell with a pseudo-terminal, sends commands as keystrokes, and detects the prompt after each command. This is what Netmiko, Ansible network_cli, Scrapli, and most real-world network automation tools use. Many network devices don’t support exec mode properly, and automation tools need prompt detection, pagination control, and mode transitions. (Part 1 called this the “screen-scraping tax”, the cost of parsing an unstructured byte stream.)

The PTY benchmark includes session preparation (sending terminal length 0 and terminal width 511 before the first command) and per-command echo verification (reading until the echoed command appears, then reading until the prompt), matching the protocol-level behavior common to all major tools.

Mode	What it measures
`ssh/pty-fresh`	Full SSH lifecycle + PTY + shell + session prep + commands with echo verification
`ssh/pty-reuse`	Shared connection, new PTY/shell per iteration with session prep

HTTPS Modes

Mode	What it measures
`https/fresh-conn`	New TCP + TLS handshake per iteration (`DisableKeepAlives: true`)
`https/keep-alive`	Single TCP + TLS connection reused across all iterations (default HTTP behavior)
`https/batch-post`	All commands in one POST body (`/admin/config`)
`https/multi-cmd`	All commands in one GET request (ASA `/admin/exec/cmd1/cmd2` syntax)

Each mode runs N iterations, each executing 5 show version commands. The client reports min, max, average, p50, p95, and standard deviation.

Running It Yourself

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


git clone https://github.com/lykinsbd/clibench.git
cd clibench
go build -o bin/bench ./cmd/bench/

# Baseline - no added latency (no root needed)
./bin/bench -latency local -iterations 20 -commands 5

# US backbone - 30ms RTT (requires root for tc netem)
sudo ./bin/bench -latency regional -iterations 20 -commands 5

# US to Hong Kong - 150ms RTT
sudo ./bin/bench -latency intercontinental -iterations 20 -commands 5

# Fallback: userspace delay injection (no root, less accurate)
./bin/bench -latency regional -iterations 20 -commands 5 -userspace

clibench embeds its own server. No separate process needed. Non-local profiles require root (or CAP_NET_ADMIN) for tc netem on the loopback interface. Output is JSON.

Results

5 commands per iteration, all times in milliseconds (average of 20 iterations). Latency injected via tc netem on the loopback interface.

At zero latency, SSH exec mode is the fastest option. There’s no round-trip penalty, and SSH’s binary framing has less per-message overhead than HTTP headers + TLS:

The moment real network latency enters the picture, the result flips. At 30ms RTT, a US backbone path per Verizon’s March 2026 measurements, HTTPS batch is 16.8x faster than SSH PTY fresh and 15.9x faster than SSH exec fresh-conn:

At intercontinental distances (US ↔ Hong Kong, 150ms RTT), SSH PTY fresh takes 2.6 seconds for 5 commands. SSH exec fresh takes 2.4 seconds. HTTPS batch does it in 151ms:

Exec Mode vs PTY/Shell Mode

The PTY overhead comes from session preparation (terminal length 0, terminal width 511) and per-command echo verification. At higher latencies, this adds up:

Profile	RTT	SSH exec fresh	SSH PTY fresh	PTY overhead
local	0ms	3.9ms	4.3ms	+0.4ms
campus	2ms	40ms	42ms	+2ms
regional	30ms	494ms	522ms	+28ms
continental	70ms	1,144ms	1,213ms	+69ms
intercontinental	150ms	2,412ms	2,565ms	+153ms

The PTY overhead scales linearly with RTT because the session prep commands add roughly one extra round trip of overhead before the first real command runs. At 150ms RTT, that’s ~150ms of pure protocol overhead. And this is the best case. Real devices add processing time, ANSI escape codes, and prompt detection regex that the emulator doesn’t capture.

Speedup vs SSH PTY fresh (what most tools actually use)

Profile	RTT	SSH exec fresh	SSH reuse	HTTPS keep-alive	HTTPS batch
local	0ms	1.1x	3.9x	7.2x	19.1x
campus	2ms	1.1x	1.8x	3.3x	16.3x
regional	30ms	1.1x	1.7x	3.3x	16.8x
continental	70ms	1.1x	1.7x	3.4x	16.3x
intercontinental	150ms	1.1x	1.7x	3.4x	17.0x

What the Numbers Say

All results are from 20 iterations per profile. Variance was low, at regional (30ms), SSH exec fresh-conn p50 was 492ms with p95 at 508ms.

At zero latency, SSH exec wins. When there’s no network delay, TLS handshake overhead dominates. SSH exec fresh-conn takes 3.9ms; HTTPS fresh-conn takes 12.0ms. But PTY mode is already slower at 4.3ms due to session prep overhead. The reuse modes tell a different story: SSH exec reuse (1.1ms) and HTTPS keep-alive (0.6ms) are both sub-millisecond. Once the handshake is amortized, both protocols are fast.

Most automation tools don’t use exec mode. As covered above, they use PTY/shell mode for prompt detection, pagination control, and mode transitions. The PTY numbers are what your automation actually experiences.

SSH reuse helps, but not enough. Sharing one SSH connection (the ControlMaster pattern) eliminates the handshake cost, but each command still requires its own round trips. The improvement is consistent at ~1.7x. Real, but modest.

HTTPS keep-alive is ~3.4x faster at any real latency. Every HTTP client library does connection pooling by default. You don’t have to configure anything special. Just reuse the http.Client. At 30ms RTT, that’s 158ms vs 522ms (PTY fresh).

HTTPS batch is ~17x faster. Batching all commands into a single HTTP request eliminates per-command round trips entirely. The entire exchange costs one round trip regardless of command count. At 150ms RTT, that’s 151ms vs 2,565ms (PTY fresh). Unlike keep-alive (which still pays one round trip per command), batch mode pays a fixed cost regardless of command count.

The advantage grows with command count, for per-command modes. At 30ms RTT with 50 commands, SSH exec fresh-conn takes 3,253ms. SSH PTY fresh takes 1,912ms (PTY avoids per-command channel overhead but pays per-command echo verification). HTTPS keep-alive takes 1,548ms. But HTTPS batch takes just 33ms. A ~99x improvement over exec fresh and ~58x over PTY fresh. SSH batch-exec shows the same flat scaling (~250ms regardless of command count), confirming this is a property of batching, not the transport.

What This Means at Scale

If you’re managing 100 devices serially (worst case, no concurrency), using PTY mode (what Netmiko/Ansible actually do):

Profile	RTT	SSH PTY fresh (total)	HTTPS batch (total)	Time saved
regional	30ms	52s	3.1s	49s
continental	70ms	121s (2.0 min)	7.4s	114s
intercontinental	150ms	257s (4.3 min)	15s	242s (4.0 min)

Concurrency shrinks the wall time, but the per-device cost stays the same. At 150ms RTT with 10 concurrent workers against 1,000 devices, SSH PTY takes ~4.3 minutes of wall time. HTTPS batch takes ~15 seconds.

Limitations

This benchmark measures transport overhead, not device processing time. Real network devices add their own latency to command execution: parsing the command, generating output, writing to the terminal. That cost is the same regardless of transport, so it doesn’t affect the relative comparison.

The HTTPS server uses a self-signed certificate with no session resumption. TLS 1.3 0-RTT resumption would make the HTTPS numbers even better on repeated connections, but I didn’t implement it because most device management scenarios don’t maintain long-lived TLS sessions.

A -userspace flag is available as a fallback for environments where root isn’t available, but it under-counts SSH round trips due to write coalescing in Go’s crypto/ssh. The published numbers all use tc netem.

What’s Next

In Part 3, I’ll look at what happens when you can’t change the device: the proxy pattern. Move SSH to the edge, talk HTTPS over the WAN, and capture most of the improvement without touching a single device config.

The benchmark code already supports proxy mode. Try it yourself and see what your numbers look like.

CLI Over HTTPS Part 1: The Protocol Tax

brett@network-notes.com (Brett Lykins) — Tue, 28 Apr 2026 09:00:00 +0000

During my six years at Rackspace, we spent a lot of time thinking about how to interact with network devices faster. We had tens of thousands of them; firewalls, load balancers, switches, routers and more, all spread across multiple data centers on four continents.

In the early days, managing devices across these data centers meant running shell scripts, Expect, or Perl from local machines and centralized bastions over the WAN. It was operationally painful. SSH connections to devices on other continents were slow enough that teams scheduled automation runs around maintenance windows not just because of the change itself, but because of how long it took to deliver the changes.

An Erlang-based platform solved this by co-locating the SSH connections with the devices. They ran inside each data center, talking SSH to devices over local links where the protocol overhead was negligible. Phil Toland presented the Erlang architecture at Erlang Factory 2012, detailing Erlang and Ruby managing backups and automation for 20,000+ network devices across 8 data centers. My team later supplemented it with a Go microservices architecture to provide API-driven access to device CLIs. Both systems were effective not just because of language capabilities; crucially they were fast because SSH stayed local.

But, even with co-located endpoints, the Cisco ASA fleet was a special case which tested our capabilities due to the extreme size of some of the Access Lists. That’s when someone discovered that the ASA has an HTTP interface we could use. Not the ineffective ASA Java-based REST API, but an actual CLI-over-HTTPS endpoint used by the ASDM client. There was a URL on the device where you could send the same commands you’d type into an SSH session, but over an HTTPS request. We tried it as an experiment, and it was remarkably faster. What started as a curiosity became a production lifesaver for our ASA fleet.

I’ve been thinking about that experience ever since, and I finally decided to quantify it properly. In this series of posts, I will quantify the performance difference between SSH and HTTPS as CLI transports and explain why the gap exists.

The SSH Tax

For a deeper look at SSH’s protocol layers, channel types, and how NETCONF and RESTCONF fit in, see What Actually Happens When You SSH Into a Router.

When your automation tool opens an SSH connection to a network device, here’s what actually happens on the wire before a single byte of command output comes back. (Throughout this series, “RT” means a round trip: one message out, one message back. “RTT” is the round-trip time in milliseconds for a given network path.)

1. TCP three-way handshake. SYN, SYN-ACK, ACK. One round trip. (The ACK can piggyback on the first data segment, but the connection isn’t usable until the handshake completes.)

2. Protocol version exchange. Client and server each send an identification string (SSH-2.0-OpenSSH_9.6). Another round trip.

3. Key exchange. The client and server negotiate algorithms (encryption, MAC, compression) via KEXINIT, then perform a Diffie-Hellman key exchange. This takes 1-3 round trips depending on whether the KEXINIT messages cross in flight and which DH group is negotiated.

4. Service request. The client requests the ssh-userauth service. One round trip.

5. User authentication. Password or public key auth. 1-3 round trips depending on how many methods the server probes (GSSAPI, publickey, then password, each one a round trip).

6. Channel open. SSH multiplexes channels over a single connection. Opening a session channel is another round trip.

That’s 6-10 round trips just to get an authenticated channel. If you’re running a single exec-style command, add one more round trip for the request/response and you’re done.

But automation tools don’t use exec mode. Netmiko, Ansible, and Scrapli open a PTY/shell channel, which adds:

7. PTY request. Ask the server for a pseudo-terminal. One round trip.

8. Shell request. Start an interactive shell on that PTY. One round trip.

9. Session prep. Send terminal length 0, terminal width 511, and wait for each prompt. Two to three more round trips.

Add it up: 10-15 round trips before you see the output of show version, with most real-world automation sessions landing at 10-12. The SSH3 project cites similar overhead in their motivation for building SSH over HTTP/3.

SSH multiplexing (ControlMaster) amortizes the connection setup cost across sessions, but the first connection still pays the full overhead. It helps for repeated connections to the same device, but doesn’t solve the problem at scale across thousands of hosts.

At zero latency (localhost), nobody cares. At real-world distances, it compounds fast.

What This Costs at Real Distances

Verizon Enterprise publishes monthly backbone latency measurements from their global network. Here’s what SSH connection setup costs at those measured round-trip times, assuming 10-15 round trips for a typical PTY/shell automation session:

Path	Measured RTT	SSH setup (10-15 RT)	Source
US backbone (intra-region)	30ms	300-450ms	Verizon Mar 2026: 29.9ms
Transatlantic (NYC ↔ London)	70ms	700-1,050ms	Verizon Mar 2026: 70.2ms
US ↔ Hong Kong	146ms	1,460-2,190ms	Verizon Mar 2026: 145.5ms
US ↔ New Zealand	174ms	1,740-2,610ms	Verizon Mar 2026: 174.2ms

That’s just connection setup. You haven’t sent a command yet. And if your automation opens a fresh SSH connection per device, or per task, which is Ansible’s default behavior without ControlMaster, you pay this cost repeatedly.

A thousand devices at 30ms RTT without concurrency: 300-450 seconds of pure SSH handshake overhead. At 150ms RTT: 1,500-2,250 seconds. Concurrency reduces wall time, but every device still pays the full per-connection cost.

The Screen-Scraping Tax

SSH’s round-trip overhead is only half the story. The other half is what happens after you connect.

SSH gives you a byte stream. A pseudo-terminal. Your automation tool has to:

Detect the prompt to know when command output is complete. Netmiko does this with regex matching on every chunk of bytes received, waiting for a pattern like hostname#. If the output is large or arrives in small TCP segments, this means multiple read cycles.
Handle pagination. --More-- prompts. Most tools send terminal length 0 first, which is another command round trip.
Navigate mode transitions. enable, configure terminal, interface GigabitEthernet0/0. Each one is a command, a prompt change, and a round trip.
Wait for command completion. Netmiko’s default read_timeout adds deliberate delays to avoid reading partial output.

None of this is Netmiko’s fault. It’s doing the best it can with what SSH gives it: an unstructured byte stream with no framing, no content-length, no end-of-message delimiter. The tool has to infer when the device is done talking. Compare that to HTTPS (Content-Length), NETCONF (]]>]]> delimiter), or even SSH exec mode (exit codes). PTY is the only mode where the client has to guess when the response is complete.

The HTTPS Alternative

Now consider what happens when you send the same command over HTTPS:

1. TCP three-way handshake. Same as SSH. One round trip.

2. TLS 1.3 handshake. 1 round trip. (TLS 1.2 was 2 round trips; TLS 1.3 cut it in half. With session resumption, it’s 0 round trips.)

3. HTTP request/response. Send the command, get the output. 1 round trip.

Total: about 3 round trips for a fresh connection. With connection reuse (HTTP keep-alive, which every HTTP client library does by default): 1 round trip per command after the first.

Side by side, the difference is stark. Here’s the same operation (5 commands at 30ms RTT) over both protocols:

And here’s the part that changes the math entirely: you can batch commands. The Cisco ASA HTTP interface accepts multiple commands in a single request, either slash-separated in the URL or newline-delimited in a POST body. Ten commands, one request, one response. That’s 1 round trip for 10 commands, vs SSH where each command requires its own channel-open and exec round trips.

No prompt detection. No pagination handling. No mode transitions. The response body is the command output, with a proper HTTP Content-Length header. Your client knows exactly when the response is complete.

Prior Art: The Cisco ASA HTTP Interface

This isn’t a theoretical proposal. Cisco has shipped an HTTP-based CLI interface on the ASA for years. Their own documentation opens with this:

One way to interface with most network appliances including ASAs is via CLI. An automated tool could Telnet or SSH into a device, authenticate and execute commands, one at a time. This method has a number of drawbacks, however. The tool must maintain the state of the Telnet and SSH connection, and if that connection is broken, the login process has to be repeated. Using CLI, it is only possible to send one command at a time, so administering many firewalls would be time consuming, especially when the firewalls are some latency away from the management station.

Cisco identified the exact problem and shipped a solution. The interface is straightforward:

1
2
3
4
5
6
7
8
9


# Single command
curl -sk -u admin:admin https://asa.example.com/admin/exec/show+version

# Multiple commands in one request
curl -sk -u admin:admin https://asa.example.com/admin/exec/show+version/show+ip+interface+brief

# Bulk config push
curl -sk -u admin:admin -X POST --data-binary @config.txt \
 https://asa.example.com/admin/config

Basic auth over TLS. URL-encoded commands in the path. Newline-delimited commands in a POST body. No SDK, no client library, no special protocol. Just HTTPS.

Aaron Hackney, another principal engineer at Rackspace at the time who was dealing with the same fleet of ASAs, went deep on this interface in a BRKSEC-2031 session at Cisco Live Orlando 2018. The work involved reverse-engineering the ASDM client’s HTTP calls and building Python tooling to script against the same interface. The two-part Cisco community blog series that followed is still one of the best references for anyone looking to automate ASAs over HTTPS instead of SSH.

“Great, but My Switches Don’t Have an HTTPS CLI”

The network automation community has spent a decade building tooling around SSH. Netmiko, Paramiko, Ansible’s network_cli, Nornir, NAPALM. All SSH-based for CLI interaction. That investment is real and valuable. NETCONF and gNMI exist as alternatives, but they require device support for structured data models. A different paradigm entirely. Many organizations have thousands of CLI commands, templates, and playbooks that work. They don’t need a new data model. They need a faster pipe.

And the ASA’s HTTP interface is the exception, not the rule. Most network platforms (IOS, NX-OS, EOS, Junos) don’t expose their CLI over HTTPS. Realistically, that’s not going to change across the industry without a major shift in how vendors think about management plane interfaces. I’m not holding my breath.

But the protocol overhead problem doesn’t go away just because the devices don’t support the better transport natively. So what do you do?

You move the expensive SSH transactions to the edge. Put a lightweight proxy, an API gateway, a microservice, whatever you want to call it, close to the devices it manages. That proxy talks SSH to the devices over a low-latency local network where the round-trip overhead is negligible. Your automation platform talks HTTPS to the proxy over the WAN, where the round-trip savings actually matter.

The pattern looks like this: your centralized automation (Ansible, Nornir, custom tooling) sends an HTTPS request to a proxy co-located with the devices. The proxy opens an SSH session to the device on a 1-2ms local link, executes the commands, and returns the output in the HTTP response. Your automation never touches SSH directly. It gets the speed of HTTPS over the WAN and the compatibility of SSH on the last hop.

This isn’t hypothetical. It’s the architecture behind tools like my NAAS (Netmiko as a Service) application, which wraps Netmiko’s SSH sessions behind a REST API. Deploy a NAAS instance in each region or data center, and your automation talks HTTP to the nearest one. The SSH overhead stays local. The WAN traffic is pure HTTPS.

In Part 2, I’ll detail a dual-protocol device emulator I built in Go that serves the same commands over both SSH and HTTPS, and a benchmark client that measures the difference at realistic latencies. The code is already public if you want to run ahead.

My take: SSH is a fine protocol for interactive terminal sessions. It’s a poor protocol for automation at scale. The round-trip overhead is baked into the protocol design, and no amount of connection pooling or multiplexing fully eliminates it. HTTPS with TLS 1.3 is a strictly better transport for the “send command, get output” pattern that defines CLI automation. The industry should be building toward it.

What Actually Happens When You SSH Into a Router

brett@network-notes.com (Brett Lykins) — Thu, 23 Apr 2026 11:00:00 +0000

You type ssh router1, hit enter, and a prompt appears. Simple.

Between those two events, your client and the device exchange dozens of packets across three protocol layers, negotiate cryptographic algorithms, perform a key exchange, authenticate you, open a channel, and (if you’re using a tool like Netmiko) request a pseudo-terminal, detect the prompt, disable pagination, and set the terminal width. All before a single show command runs.

Most network engineers use SSH every day without thinking about any of this. That’s fine for interactive use. But if you’re building automation that opens hundreds or thousands of SSH sessions, every one of those steps costs at least one network round trip (sometimes more), and round trip times are usually the single biggest factor in how fast your automation runs.

SSH Is Three Protocols, Not One

SSH isn’t a single protocol. RFC 4251 describes it as “three major components,” each defined in its own RFC:

Component	RFC	What it does
Transport	RFC 4253	Key exchange, encryption, integrity, server authentication
Authentication	RFC 4252	User authentication (password, publickey, keyboard-interactive)
Connection	RFC 4254	Channels, multiplexing, port forwarding, sessions

A fourth RFC, RFC 4251 (Architecture), defines the overall design, terminology, and trust model. It’s the framework that ties the three wire protocols together.

Each layer runs on top of the previous one. The transport layer gives you an encrypted pipe. The authentication layer proves who you are. The connection layer multiplexes that pipe into channels, and channels are where the actual work happens.

The application (your shell session, your show version command, your NETCONF RPC) rides on top of a channel.

TCP

SSH runs over TCP; so before any SSH packets flow, you need a TCP connection:

Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK

Cost: 1 round trip. The ACK can piggyback on the first SSH data, but the connection isn’t usable until the handshake completes.

This is the same cost every TCP-based protocol pays. Nothing SSH-specific yet.

SSH Transport

Protocol Version Exchange

Immediately after TCP connects, both sides send an identification string:

1
2


SSH-2.0-OpenSSH_9.6
SSH-2.0-Cisco-1.25

Both sides send simultaneously, so this can overlap with the TCP ACK. In practice, the client usually sends first and waits for the server’s response.

Cost: 1 round trip for the version exchange. Implementations vary on whether KEXINIT is pipelined with the version string or sent after receiving the server’s version.

Algorithm Negotiation (KEXINIT)

Both sides send SSH_MSG_KEXINIT, a packet listing every algorithm they support, in preference order:

Key exchange methods (e.g., curve25519-sha256, diffie-hellman-group14-sha256)
Host key algorithms (e.g., ssh-ed25519, rsa-sha2-512)
Encryption algorithms (e.g., aes256-gcm@openssh.com, chacha20-poly1305@openssh.com)
MAC algorithms (e.g., hmac-sha2-256-etm@openssh.com)
Compression algorithms (usually none)

RFC 4253 says “key exchange will begin immediately after sending [the version] identifier,” meaning each side can fire off its KEXINIT right after its version string without waiting. If both sides do this, the KEXINIT packets arrive during the same round trip as the version exchange, and the cost is zero additional round trips. If the client waits for the server’s version string before sending KEXINIT (which some implementations do), it costs a separate round trip.

Cost: 0-1 round trips depending on whether the implementation pipelines KEXINIT with the version string.

Key Exchange

The exact packet sequence depends on the algorithm:

Modern (curve25519-sha256, ecdh-sha2-nistp256): 1 round trip.

Client → Server: SSH_MSG_KEX_ECDH_INIT (client’s ephemeral public key)
Server → Client: SSH_MSG_KEX_ECDH_REPLY (server’s ephemeral public key + host key + signature)

Both sides now have a shared secret. The server’s signature proves it holds the private key matching the host key the client expects.

Legacy (diffie-hellman-group-exchange-sha256): 2 round trips.

Client → Server: SSH_MSG_KEX_DH_GEX_REQUEST (preferred group size)
Server → Client: SSH_MSG_KEX_DH_GEX_GROUP (prime and generator)
Client → Server: SSH_MSG_KEX_DH_GEX_INIT (client’s public value)
Server → Client: SSH_MSG_KEX_DH_GEX_REPLY (server’s public value + signature)

The extra round trip exists because the client asks the server to choose a DH group, rather than using a fixed one. Older network devices that don’t support curve25519 or ECDH may force this path.

Cost: 1-2 round trips depending on the algorithm.

After key exchange completes, both sides send SSH_MSG_NEWKEYS simultaneously to activate the new keys (no additional round trip). The client then requests the ssh-userauth service via SSH_MSG_SERVICE_REQUEST / SSH_MSG_SERVICE_ACCEPT, costing 1 round trip. Some implementations (like OpenSSH) pipeline this with NEWKEYS, but many wait.

Transport layer total: 3-5 round trips (TCP + version exchange + KEXINIT + kex + service request).

SSH Authentication

The client now needs to authenticate. This is where things get variable, because the server controls which methods it accepts and in what order.

The Auth Dance

The client sends an authentication request. If it fails or the server wants to advertise available methods, the server responds with SSH_MSG_USERAUTH_FAILURE plus a list of methods that can continue.

A typical sequence for password auth:

Client → Server: SSH_MSG_USERAUTH_REQUEST (method: “none”) to discover available methods
Server → Client: SSH_MSG_USERAUTH_FAILURE (methods: “publickey,password”)
Client → Server: SSH_MSG_USERAUTH_REQUEST (method: “password”, password: “…”)
Server → Client: SSH_MSG_USERAUTH_SUCCESS

Cost: 2 round trips for password auth with a method probe.

For public key auth, it’s often 2-3 round trips:

Probe (1 RT)
Public key query: “will you accept this key?” (1 RT)
Actual signature-based auth (1 RT)

Some servers skip the probe if the client guesses correctly on the first try. Some clients try multiple key types before finding one the server accepts. Each failed attempt is another round trip.

Authentication total: 1-3 round trips depending on method and implementation.

SSH Connection

With an authenticated, encrypted connection established, the client can now open channels. For automation, this layer matters most, because there are three fundamentally different ways to interact with a device.

Channel Basics

Every channel follows the same lifecycle:

Client → Server: SSH_MSG_CHANNEL_OPEN (channel type, initial window size)
Server → Client: SSH_MSG_CHANNEL_OPEN_CONFIRMATION (window size, max packet size)
… data flows …
Either side: SSH_MSG_CHANNEL_CLOSE

Cost: 1 round trip to open a channel.

SSH channels have their own flow control, independent of TCP, with each side advertising a receive window size.

Channel Type 1: Shell (PTY)

This is what happens when you type ssh router1 and get an interactive prompt. It’s also what Netmiko, Ansible network_cli, and Scrapli use for automation.

After opening a session channel:

Client → Server: SSH_MSG_CHANNEL_REQUEST (type: “pty-req”, terminal type, dimensions)
Server → Client: SSH_MSG_CHANNEL_SUCCESS
Client → Server: SSH_MSG_CHANNEL_REQUEST (type: “shell”)
Server → Client: SSH_MSG_CHANNEL_SUCCESS

Cost: 2 round trips (PTY request + shell request).

Now you have a byte stream. The server sends a prompt (router1#). You send characters. The server echoes them back. You send a newline. The server processes the command and sends the output, followed by another prompt.

The catch: there is no framing. The server doesn’t tell you “the command output is 847 bytes long” or “I’m done sending.” It just sends bytes. Your automation tool has to figure out when the output is complete by pattern-matching the prompt, which is why Netmiko spends so much effort on prompt detection, and why it sends terminal length 0 (to disable pagination) and terminal width 511 (to prevent line wrapping) before running any real commands.

Each of those setup commands is another write-read-prompt cycle on the channel.

Channel Type 2: Exec

This is what happens when you run ssh router1 "show version" from the command line. It’s also what Go’s x/crypto/ssh, Paramiko’s exec_command(), and some other programmatic SSH libraries in various languages use.

After opening a session channel:

Client → Server: SSH_MSG_CHANNEL_REQUEST (type: “exec”, command: “show version”)
Server → Client: SSH_MSG_CHANNEL_SUCCESS
Server → Client: SSH_MSG_CHANNEL_DATA (command output)
Server → Client: SSH_MSG_CHANNEL_REQUEST (type: “exit-status”, code: 0)
Server → Client: SSH_MSG_CHANNEL_CLOSE

Cost: 1 round trip for the exec request, then the output streams back.

Exec mode is cleaner than shell mode: one command, one channel, structured exit. No prompt detection, no pagination, no terminal width issues. But there are some catches.

First, each command needs its own channel. If you want to run 5 commands, you open 5 channels, meaning 5 channel-open round trips plus 5 exec-request round trips.

Second, many network devices don’t support exec mode properly (or at all), which is why most automation tools default to shell/PTY mode.

Channel Type 3: Subsystem (NETCONF)

NETCONF (RFC 6241) runs over SSH as a subsystem, a named service that the server knows how to handle.

After opening a session channel:

Client → Server: SSH_MSG_CHANNEL_REQUEST (type: “subsystem”, name: “netconf”)
Server → Client: SSH_MSG_CHANNEL_SUCCESS

Cost: 1 round trip.

Then NETCONF has its own handshake on top of the SSH channel:

Both sides simultaneously: <hello> messages listing capabilities
Client → Server: <rpc> request
Server → Client: <rpc-reply> response

The <hello> exchange is 1 round trip. Each RPC is 1 round trip. Messages are delimited by ]]>]]> (the legacy base:1.0 framing) or chunked framing with \n#length\n headers (base:1.1), both defined in RFC 6242.

NETCONF gives you structured XML data and transactional semantics (<edit-config>, <commit>, <validate>), which beats screen-scraping CLI output by a wide margin. But it pays the full SSH transport cost to get there, plus its own capability exchange overhead.

The Round-Trip Tally

Here’s what it all adds up to, from TCP SYN to first byte of command output:

Step	Round trips	Notes
TCP handshake	1	Same for any TCP protocol
SSH version exchange + KEXINIT	1-2	Pipelined: 1 RT; sequential: 2 RT
Key exchange (modern)	1	curve25519/ECDH
Key exchange (legacy)	2	DH group exchange
NEWKEYS + service request	1	Often pipelined
Authentication	1-3	Password: 2, pubkey: 2-3
Channel open	1
PTY + shell request	2	Shell/PTY mode only
Exec request	1	Exec mode only
Subsystem request	1	NETCONF only
NETCONF hello exchange	1	NETCONF only

SSH CLI (exec mode): 6-10 round trips before the first command output.

SSH CLI (PTY/shell mode): 7-11 round trips before the first command output, plus 2-3 more for session prep (terminal length 0, terminal width 511).

NETCONF over SSH: 7-11 round trips before the first RPC response, plus 1 for the NETCONF hello exchange.

For comparison:

HTTPS (TLS 1.3): 3 round trips total: TCP (1) + TLS 1.3 handshake (1) + HTTP request (1). With connection reuse: 1 round trip per request.

NETCONF vs RESTCONF: Same Data, Different Pipe

So far this post has been about what happens inside an SSH connection. But SSH isn’t the only way to talk to a network device programmatically. NETCONF and RESTCONF both operate on YANG data models, and they can configure the same things on the same devices. The difference is the transport.

	NETCONF	RESTCONF
Transport	SSH (subsystem channel)	HTTPS
Data format	XML	JSON or XML
Connection setup	7-11 RT (SSH)	3 RT (TLS 1.3)
Per-operation cost	1 RT (RPC request/reply)	1 RT (HTTP request/response)
Connection reuse	SSH connection persists	HTTP keep-alive (default)
Framing	`]]>]]>` or chunked	HTTP Content-Length
Capabilities	Explicit hello exchange	YANG library (RFC 7895)
Transactions	`<commit>`, `<validate>`, `<discard-changes>`	No candidate datastore; edits apply immediately to running config

NETCONF’s advantage is its transactional model: candidate configs, commit/rollback, validation. RESTCONF trades some of that for a simpler transport with lower connection overhead and native compatibility with standard HTTP client libraries and load balancers.

For automation at scale, the transport cost matters. If you’re making hundreds of NETCONF calls across a WAN, you’re paying the SSH handshake tax on every new connection. RESTCONF over HTTPS with connection reuse eliminates that entirely.

I’m planning to benchmark both SSH CLI vs HTTPS CLI and NETCONF vs RESTCONF with real measurements: same device, same operations, same latency profiles. Theory is useful, but packet captures don’t lie.

Why This Matters for Automation

If you’re managing 1,000 devices across a WAN with 75ms latency, the math gets ugly. Each SSH PTY/shell connection pays 675-1,050ms in handshake overhead before it does anything useful. Parallelism helps with wall clock time, but it doesn’t reduce the per-device tax, and every one of those connections is burning round trips, file descriptors, and CPU on your automation host.

I’ll be measuring this gap with real numbers in an upcoming series on CLI over HTTPS. Early testing shows that at 30ms RTT, HTTPS batch mode is roughly 5x faster than SSH for the same CLI commands, because it pays 3 round trips instead of 10-15.

My take: SSH is a good protocol for what it was built for: giving one person a secure shell on one machine. Every layer in the stack exists for a reason. But those layers add up to a lot of round trips, and that cost compounds when you’re hitting a thousand devices over a WAN. The protocol wasn’t designed for “blast 5 commands at 1,000 boxes as fast as possible.” Once you see the round-trip tax on the wire, the performance gap between SSH and HTTPS stops being surprising.

CiSSHGo: A Lightweight SSH Device Emulator for Network Automation Testing

brett@network-notes.com (Brett Lykins) — Mon, 20 Apr 2026 00:00:00 +0000

You need to test your network automation code. You’ve got an Ansible playbook that configures interfaces across a thousand switches, or a Nornir script that collects show version from every device in your inventory, and you need to know it works before it hits production.

The standard answer is “spin up a lab.” CML, EVE-NG, GNS3, ContainerLab — all solid tools that run actual NOS images. They give you real device behavior, real protocol interactions, real forwarding planes. They’re also heavy. A single Cisco CSR1000v image wants 4GB of RAM. Multiply that by the number of devices in your test topology and you’re looking at serious compute just to validate that your automation sends the right commands and parses the output correctly.

For a lot of automation testing, you don’t need a real forwarding plane. You need something that accepts an SSH connection, presents a prompt, and responds to show version with the right output. That’s what CiSSHGo does.

What CiSSHGo Is (and Isn’t)

CiSSHGo is a single Go binary that spawns SSH listeners, each emulating a network device by playing back pre-defined command transcripts. You define what commands a device supports and what output it returns, and CiSSHGo handles the SSH session, prompt rendering, command matching, and context transitions (> → # → (config)# → (config-if)#).

It is not a network simulator. There’s no forwarding plane, no routing protocol adjacencies, no MAC address table. It doesn’t run IOS or EOS or Junos. It plays back text files. That constraint is also its strength: a single CiSSHGo process can spawn thousands of SSH listeners using Go’s goroutine-per-listener model, each consuming a few kilobytes of memory. Try that with a Python-based mock server or a fleet of virtual routers.

If you’re thinking “why not ContainerLab?” — different tool for a different job. ContainerLab runs real NOS images in containers, which gives you protocol adjacencies and a real forwarding plane at the cost of per-device resource overhead. CiSSHGo gives you SSH session fidelity at massive scale with near-zero overhead. FakeNOS is the closest analog — same concept, Python-based. CiSSHGo’s Go runtime gives it an edge on concurrency and memory when you’re scaling to thousands of listeners.

CiSSHGo isn’t new. Tony Nealon (tbotnz, also the creator of netpalm) first published it in August 2020, and it’s been in active use since. I’ve been a contributor and have used it as the SSH mock backend in my own projects. What is new is the scope of recent work: the project went from a single-platform proof of concept to a v1.0.0 stable release in March 2026 with multi-vendor support, an inventory system, scenario mode, and proper release engineering. That’s enough of a capability jump to warrant a re-introduction for anyone who hasn’t looked at it recently. It’s MIT licensed, ships as pre-built binaries for Linux/macOS/Windows (amd64 and arm64), and publishes multi-arch Docker images to GitHub Container Registry.

Capabilities

Seven Platforms Out of the Box

CiSSHGo ships with transcript libraries for seven platforms: Cisco CSR1000v, IOS, IOS-XR, ASA, NX-OS, Arista EOS, and Juniper Junos. Each platform comes with show version, show ip interface brief (or equivalent), and show running-config transcripts sourced from NTC Templates test fixtures.

The transcript map is a YAML file that defines everything about a platform — hostname, credentials, supported commands, context hierarchy, and prompt format:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


platforms:
 csr1000v:
 vendor: "cisco"
 hostname: "cisshgo1000v"
 username: "admin"
 password: "admin"
 command_transcripts:
 "show version": "cisco/csr1000v/show_version.txt"
 "show ip interface brief": "cisco/csr1000v/show_ip_interface_brief.txt"
 "show running-config": "cisco/csr1000v/show_running-config.txt"
 "terminal length 0": "generic_empty_return.txt"
 context_hierarchy:
 "(config-if)#": "(config)#"
 "(config)#": "#"
 "#": ">"
 ">": "exit"
 context_search:
 "interface": "(config-if)#"
 "configure terminal": "(config)#"
 "enable": "#"
 "base": ">"

Adding a new platform or new commands is just adding text files and YAML entries. No Go code required.

Inventory Mode

For testing against multiple device types, CiSSHGo supports an inventory file that spawns different platforms on different ports from a single process:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


devices:
 - platform: csr1000v
 count: 10
 - platform: ios
 count: 10
 - platform: nxos
 count: 10
 - platform: eos
 count: 10
 - platform: junos
 count: 10

One binary, 50 SSH listeners, five different platform personalities. Each gets its own hostname, credentials, prompt style, and command set.

Scenario Mode

Scenario mode is the feature that moved CiSSHGo from “useful for smoke tests” to “useful for real integration testing.” A scenario defines an ordered sequence of commands with different outputs at each step. The classic use case: show running-config returns one output before a configuration change and different output after.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


scenarios:
 csr1000v-add-interface:
 platform: csr1000v
 sequence:
 - command: "enable"
 transcript: "generic_empty_return.txt"
 - command: "show running-config"
 transcript: "scenarios/csr1000v-add-interface/running_config_before.txt"
 - command: "configure terminal"
 transcript: "generic_empty_return.txt"
 - command: "interface GigabitEthernet0/0/2"
 transcript: "generic_empty_return.txt"
 - command: "ip address 172.16.0.1 255.255.255.0"
 transcript: "generic_empty_return.txt"
 - command: "no shutdown"
 transcript: "generic_empty_return.txt"
 - command: "end"
 transcript: "generic_empty_return.txt"
 - command: "show running-config"
 transcript: "scenarios/csr1000v-add-interface/running_config_after.txt"

Each SSH session gets its own sequence pointer. Commands that don’t match the current step fall through to the platform’s normal command set. Scenario mode also handles interface abbreviation matching — int g0/0/2 matches interface GigabitEthernet0/0/2 without a hardcoded abbreviation table. The sequence step itself provides the ground truth.

Flexible Prompts

Not every NOS uses the Cisco hostname# prompt format. CiSSHGo supports a prompt_format field for platforms like Junos that use user@hostname> style prompts, and context_prefix_lines for multi-line prompts like Junos’s [edit] prefix:

1
2
3
4
5
6
7


 junos:
 vendor: "juniper"
 hostname: "cisshgo-junos"
 username: "admin"
 prompt_format: "{username}@{hostname}{context}"
 context_prefix_lines:
 "#": "[edit]"

This produces:

1
2
3
4


admin@cisshgo-junos>
admin@cisshgo-junos> configure
[edit]
admin@cisshgo-junos#

Session Behavior

Once a listener is running, CiSSHGo handles the session the way you’d expect from a real device. Commands are matched by prefix — sh ver resolves to show version, sh ip int br to show ip interface brief — and ambiguous abbreviations get the familiar % Ambiguous command error. Your automation code can use the same shortened commands it uses against real hardware.

Both interactive shell sessions and exec mode (ssh host "show version") work. Automation tools like Ansible’s network_cli use interactive shell mode, while libraries like Go’s x/crypto/ssh and Paramiko’s exec_command() use exec mode — so supporting both matters for realistic testing.

Transcript files support Go’s text/template syntax. You can reference device fields like {{.Hostname}} in your transcript output, so the same transcript file produces different output for different devices in an inventory.

Running It

The quickest path is Docker:

1

docker run -d -p 10000-10049:10000-10049 ghcr.io/tbotnz/cisshgo:latest

That gives you 50 listeners on ports 10000–10049, all emulating a CSR1000v by default. Pre-built binaries are on the releases page if you’d rather run it directly.

Every CLI flag has a corresponding environment variable (CISSHGO_LISTENERS, CISSHGO_STARTING_PORT, CISSHGO_TRANSCRIPT_MAP, CISSHGO_PLATFORM, CISSHGO_INVENTORY), so it drops into a docker-compose or Kubernetes manifest without wrapper scripts.

Where It Fits

Scale Testing

This is where CiSSHGo’s Go runtime earns its keep. If you’re building or evaluating a network automation framework that needs to handle thousands of devices, you need thousands of SSH endpoints to test against. You don’t need those endpoints to actually route packets — you need them to accept connections, authenticate, and return plausible output.

A single CiSSHGo process with --listeners 10000 spawns ten thousand SSH listeners, each running as a goroutine. Memory overhead is measured in megabytes, not gigabytes. Compare that to spinning up ten thousand virtual routers (not happening), ten thousand containers running a Python SSH server (possible but expensive), or trying to test at scale against a lab of 20 real devices and hoping the math extrapolates (it won’t — connection pooling, queue depth, and timeout behavior all change at scale).

Pair CiSSHGo with an inventory file and you get a mixed-vendor topology: a few thousand IOS devices, a few thousand NX-OS, some EOS, some Junos. Your automation framework sees what looks like a heterogeneous production network. The responses are canned, the SSH handshakes and authentication are real, and that’s exactly the layer you’re trying to test.

CI/CD Pipeline Testing

The simplest use case. Drop CiSSHGo into your CI pipeline as a service container, point your automation tests at it, and validate that your code sends the right commands and parses the output correctly. No lab infrastructure to maintain, no NOS licenses to manage, no flaky device VMs timing out mid-test.

A docker-compose snippet for a GitHub Actions workflow:

1
2
3
4
5
6
7


services:
 cisshgo:
 image: ghcr.io/tbotnz/cisshgo:v1.0.0
 command: ["--listeners", "2", "--starting-port", "10022"]
 ports:
 - "10022:10022"
 - "10023:10023"

Your test suite connects to localhost:10022, runs commands, and asserts on the output. The CiSSHGo container starts in under a second.

Integration Test Stacks

I use CiSSHGo as the mock SSH backend in the integration test suite for NAAS (Netmiko As A Service). The docker-compose stack spins up CiSSHGo alongside the API server, workers, and Redis, and the tests exercise the full request path: HTTP request → job queue → Netmiko SSH connection to CiSSHGo → response parsing → result delivery. The CiSSHGo container handles send_command, send_config, structured output parsing, platform autodetect, and authentication failure scenarios. I’ll cover that setup in detail in a future post.

Parser Development

If you’re writing or testing TextFSM or TTP templates — something I’ve written about before — you need consistent, known-good command output to parse against. CiSSHGo’s transcripts are sourced from NTC Templates test fixtures, so you get realistic output that matches what the parsing community already validates against. Point your parser at CiSSHGo, iterate on your template, and know that the input is stable between runs.

It also works for demos and training — a multi-vendor topology from a single container, no lab required. Students can SSH in and practice writing playbooks against something that responds like a real switch.

When Not to Use It

No protocol simulation. If your tests depend on BGP adjacencies forming, OSPF routes being installed, or ARP tables populating, CiSSHGo can’t help. You need CML, ContainerLab, or real hardware.
No NETCONF, gNMI, or SNMP. CiSSHGo is SSH-only. If your automation uses model-driven interfaces, look elsewhere.
No dynamic state beyond scenarios. Outside of scenario mode, every session gets the same output for the same command. There’s no simulated interface going up or down, no counter incrementing. Scenario mode adds ordered state changes, but it’s scripted, not reactive.
Transcript maintenance. Your transcripts need to match what your automation expects. If a real device’s show version output changes between NOS versions and your parser depends on the new format, you need to update the transcript. This is manageable but not zero-effort.

CiSSHGo tests your automation’s SSH interaction layer — connection handling, command dispatch, output parsing, error handling. It doesn’t test whether your automation produces correct network state. A playbook that configures BGP neighbors needs a real lab (or at minimum ContainerLab) to validate that adjacencies form and routes propagate. And no amount of pre-production testing — mock or otherwise — replaces a sensible rollout strategy: canary deployments, staged rollouts, automated validation gates. CiSSHGo fits early in that pipeline, catching the class of bugs that don’t need a forwarding plane to find. The rest of the pipeline still matters. I’ll dig into automation testing strategies and deployment patterns in a future post.

Getting Started

The GitHub repo has pre-built binaries on the releases page, Docker images on GHCR, and documentation covering configuration, transcript authoring, and the inventory system. The project is MIT licensed and accepts contributions — the CONTRIBUTING.md covers the workflow.

If you’re testing network automation against real devices or heavyweight simulators and finding it slow, flaky, or expensive to maintain — stop. Use CiSSHGo for the SSH interaction layer, save the real lab for the tests that actually need a forwarding plane.

SONiC at the Edge: Cheaper Switches Don't Mean a Cheaper Network

brett@network-notes.com (Brett Lykins) — Wed, 08 Apr 2026 10:00:00 -0500

Disclosure: I currently work on a team deploying SONiC at scale. I’m not a neutral party, but I’ll be honest about both sides of the ledger.

In Part 1, I covered the technical shift: 1G access-layer hardware now runs SONiC, the feature set is filling in, and the support ecosystem is real. If you haven’t read that yet, start there.

This post is about the question that comes after “can we?” — the “should we?” That answer has less to do with switch specs and more to do with how your organization spends money, builds teams, and tolerates risk.

The Capex-Only Trap

Everyone leads with hardware savings when pitching disaggregated networking. And the savings are real. White box switches commonly cost one-half to one-third what a comparable Cisco Catalyst or Arista switch runs, based on list-price comparisons across current 48-port 1G PoE models. At fleet scale, that delta gets attention from finance teams fast.

But hardware is the easiest line item to compare and often the smallest. One TCO analysis of a 15,000-device deployment found that purchase price represented only 25–30% of five-year costs, with the remaining 70–75% coming from deployment, management, support, and retirement. Network infrastructure tends to follow a similar pattern, though the exact ratio varies by environment. One analysis on the Network Automation Forum captured this well: an engineer cited potential savings of $1.3 million on a single edge upgrade, while others in the same discussion pointed out that compensating costs in staffing and operational complexity can eat into those numbers significantly.

Here’s what actually costs money over five years:

Staffing. Someone has to operate this network. SONiC is Linux. Your team needs to be comfortable with Debian, systemd, Docker containers, and debugging at the OS level, not just CLI-driven NOS administration. If your current team can’t do that, you’re either retraining them or hiring people who can. Both cost money.
Training. Retraining a team that’s spent a decade on IOS or EOS is a real investment. It’s not a week-long bootcamp. It’s months of building muscle memory on a fundamentally different operational model.
Tooling and management plane. Your existing monitoring, config management, and automation probably assumes a traditional NOS. Some of it ports over. Some of it gets rebuilt. That rebuild has a cost in engineering hours and in the operational risk of running new tooling in production. The bigger gap: SONiC doesn’t ship with a CloudVision or DNA Center equivalent. There’s no turnkey management plane for ZTP, firmware lifecycle, config compliance, or centralized visibility. Organizations with the scale to justify SONiC have often already built internal tooling for these functions and aren’t relying on vendor-provided platforms, which lowers this cost significantly. But if your operations today depend on a vendor management suite, budget for the engineering effort to replace it.
Wireless and adjacent systems. SONiC is a wired switching NOS. You’ll need a separate wireless management stack, which adds another operational surface and cost line. Factor in the integration work between your wired and wireless management planes. It won’t be as seamless as a single-vendor converged solution.
Support contracts. Commercial SONiC distributions aren’t free. Broadcom Enterprise SONiC, Dell Enterprise SONiC, Aviz Certified Community SONiC. They all come with support contracts. Cheaper than a Cisco SmartNet? Usually. Free? No.
Incident response. Your mean time to resolution will be longer on a new platform. That’s not a knock on SONiC. It’s true of any platform your team hasn’t operated for years. It’s especially true at the access layer, where the SONiC ecosystem is younger: Marvell Prestera SAI drivers, 1G hardware platforms, and features like PVST+ and 802.1X are all more recent and less battle-tested than their data center counterparts. Budget for it.

The BOM comparison is where the conversation starts. It shouldn’t be where it ends.

What You’re Actually Trading

The pitch for disaggregated networking is “escape vendor lock-in.” The reality is messier: you’re trading one type of dependency for another.

With a traditional vendor, the deal is straightforward. You write a check for hardware, software, and support bundled together. You get a single number to call when things break. You’re locked to their roadmap, their pricing, and their release cadence, but you’re also insulated from a lot of operational complexity. That insulation has value, and it’s easy to underestimate until it’s gone.

With SONiC and disaggregated hardware, you get procurement flexibility. You can source switches from Celestica this quarter and Edgecore next quarter. You’re not captive to one vendor’s pricing. But you take on the integration work. You own the testing matrix — every NOS version against every hardware platform against every feature combination you deploy, a validation effort that traditional vendors absorb for you. You’re responsible for validating that your NOS version works on your hardware with your feature set. That responsibility lands on your engineering team, and it doesn’t go away after the initial deployment.

The same principle applies to network disaggregation: focus on switching costs, not lock-in. Every platform has lock-in of some kind. The question is what it costs you to change. With Cisco, the switching cost is a hardware refresh and a config migration. With SONiC, the switching cost is lower on hardware but potentially higher on the operational and tooling side if you’ve built deep integrations.

There’s an upside to the trade that’s easy to overlook: with an open-source NOS, you can contribute upstream, influence the roadmap, and fix bugs yourself (or fund someone to). You’re not waiting on a vendor’s release train for a feature you need next quarter. That agency has real value for organizations with the engineering capacity to exercise it.

The honest framing: you’re not eliminating dependency. You’re moving it from a vendor relationship to an internal engineering capability. Whether that’s a good trade depends entirely on your organization.

The Scale Threshold

The business case for SONiC at the access layer is scale-dependent. This isn’t a controversial statement — it’s just math.

At small scale — say, under 100 switches — the engineering investment dominates. You’re hiring or retraining people, building tooling, standing up a lab, and absorbing the risk of a new platform. The hardware savings on 100 switches don’t cover that. Buy Meraki or Aruba, spend your engineering time on something else.

At medium scale — a few hundred switches across a handful of sites — it gets interesting but not obvious. The hardware savings start to add up, but you’re still carrying the full weight of the operational investment. This is the zone where the decision depends heavily on your team’s existing capabilities. If you already have strong automation practices and Linux-comfortable engineers, the marginal cost of adding SONiC is lower. If you’re starting from scratch on both, it’s a harder sell.

At large scale — thousands of switches across dozens or hundreds of sites — the math starts to favor SONiC, but only if the organizational readiness factors line up. The per-unit hardware savings compound across the fleet and across refresh cycles. The operational consistency argument kicks in: one NOS from spine to access port means one automation framework, one monitoring pipeline, one set of runbooks. And the negotiating power is real. When you’re buying thousands of switches, being able to source from multiple hardware vendors changes the dynamic. Scale is necessary for the business case to work, but it’s not sufficient on its own.

One thing the scale discussion often misses: “do nothing” isn’t free either. Vendor price increases compound — a 3–4% annual hardware uplift on a 2,000-switch fleet adds up over two refresh cycles. Lock-in deepens as you build more automation and tooling around a proprietary platform, raising your switching costs every year you stay. And the talent pool for legacy NOS administration is gradually shrinking as the industry shifts toward Linux-native infrastructure. The status quo has a cost trajectory too. Make sure your business case accounts for it.

The variables that determine where your break-even sits:

Fleet size. More switches = more capex savings to offset the opex investment.
Number of sites. More sites amplify both the savings (more hardware) and the complexity (more operational surface area).
Team maturity. A team that already runs infrastructure as code has a shorter ramp than one that manages everything by hand.
Contract timing. If you’re mid-cycle on a vendor contract with favorable terms, the urgency drops. If you’re facing a refresh with a steep price increase, the urgency spikes.
Greenfield vs. brownfield. New sites are easier. Migrating existing sites means running two platforms in parallel during the transition, which has its own cost.

Organizational Readiness

Before you evaluate hardware or run a PoC, ask these questions about your organization:

Does your team manage infrastructure as code today? If your network engineers are already writing Ansible playbooks, using Git, and deploying through CI/CD pipelines, the transition to SONiC is a platform change, not a paradigm change. If your workflow is “SSH into the switch and type commands,” you have a culture shift ahead of you that’s bigger than the technology shift.

Can your network engineers troubleshoot at the Linux OS level? SONiC problems don’t always look like network problems. Sometimes it’s a container that didn’t start. Sometimes it’s a systemd service in a failed state. Sometimes it’s a kernel driver issue. Your team needs to be as comfortable with journalctl and docker logs as they are with show ip bgp.

Can you recruit Linux-native network engineers? This talent pool is growing, but it’s still smaller than the pool of traditional network engineers. An EMA survey on network automation found that 27% of respondents pointed to staffing issues and skills gaps as a top challenge, with one engineer noting: “The most challenging thing for me is the lack of network engineers who can contribute to automation. The community is small, and it’s hard to find people who can help you solve a problem.” If you’re in a market where hiring is already hard, factor in the recruiting challenge. If you’re in a tech hub where Linux skills are common, this is less of a concern.

Is your organization comfortable with open-source support models? Commercial SONiC distributions come with support contracts, but the support experience is different from calling Cisco TAC. Community SONiC means GitHub issues and mailing lists. Know which model your organization can tolerate.

Do you have the patience for a multi-year build? This isn’t a forklift upgrade you execute in a quarter. It’s a capability you build over years: lab, pilot, limited production, broad rollout. A realistic timeline, in my experience: 6–12 months to stand up a lab and run a pilot, another 6–12 months for limited production at a handful of sites, and 1–2 years to reach broad rollout. Most organizations won’t see net positive ROI until year two or three, when the hardware savings across refresh cycles start outpacing the cumulative engineering investment. If your leadership expects payback in the first year, set that expectation early. Or find a different project.

If you answered “no” to most of these, SONiC isn’t necessarily the wrong choice. But your business case needs to include the cost of getting to “yes” on each one.

Building the Business Case

A credible business case has two parts: the spreadsheet and the narrative. You need both.

The spreadsheet covers what you can quantify:

Hardware cost delta: per-unit savings × fleet size × number of refresh cycles in your planning horizon
Support contract delta: commercial SONiC distribution costs vs. current vendor support
Staffing costs: new hires, training programs, potential salary premium for Linux networking skills
Tooling costs: what you build or buy to replace vendor-provided management platforms
Transition costs: lab buildout, pilot program, migration execution, parallel operation during cutover

To make this concrete: imagine a 1,000-switch fleet where white box hardware saves $2,000 per unit (a conservative estimate — Part 1 puts the delta at one-half to one-third of list price). Over two refresh cycles (roughly ten years), the capex delta is $4M. If your engineering investment is $1.5M in year one (hiring, lab, tooling) and $500K/year ongoing, you break even midway through year two. That math looks good on a slide. But if you also need to rebuild your management plane, add $500K–$1M to year one. If your team needs 12 months of ramp time before they’re productive on SONiC, push the break-even out another year. The point isn’t the specific numbers — it’s that the spreadsheet has to include all the lines, not just the hardware line.

The narrative covers what you can’t easily put in a cell:

Procurement leverage — your incumbent vendors won’t stand still. They’re actively raising prices; Cisco implemented an average ~3.4% hardware uplift in late 2025, with similar increases for technical services. Walking into a renewal with a credible SONiC PoC in your back pocket will sharpen their pencil, and that leverage is valuable even if you never deploy a single white box switch. But the reverse is also true: if your business case depends on a specific capex delta, aggressive incumbent discounting can erode it. Build your case on the operational and strategic benefits, not just the BOM savings, because the BOM savings are the part your current vendor can most easily match
Operational consistency — one NOS across your infrastructure reduces the cognitive load on your team and simplifies automation
Talent pipeline — you’re hiring from the Linux and DevOps talent pool, not just the “CCIE or equivalent” pool
Future optionality — you’re not waiting on one vendor’s roadmap for features you need. If the community or a different distro ships it first, you can adopt it
Ecosystem fragmentation risk — multiple commercial SONiC distributions (Broadcom, Dell, Aviz, Asterfusion) have different feature sets, release cadences, and proprietary extensions. Evaluate portability between distros, not just between SONiC and traditional vendors. If you build deep integrations against one distro’s proprietary MCLAG implementation, you’ve traded one form of vendor lock-in for another

Don’t oversell the savings. A business case that honestly acknowledges the tradeoffs (“we’ll save X on hardware but invest Y in engineering capability”) is more credible than one that only shows the capex delta. Decision-makers who’ve been around long enough have seen the “this will save us millions” slide deck before. They’re looking for the slide that says “here’s what could go wrong and here’s how we’ve accounted for it.”

What’s Next

This post covers whether the business case works. It doesn’t cover how you execute. If there’s interest, Part 3 will get into the operational details:

Commercial SONiC support vs. Cisco TAC in practice. Response times, escalation paths, bug fix turnaround. What “different” actually looks like when you’re troubleshooting a production outage at 2 AM.
Brownfield migration strategies. How do you actually migrate a live campus network from IOS to SONiC? Site-by-site? Building-by-building? How long do you run dual-stack, and what does parallel operation cost?
The testing and validation burden. What the NOS version × hardware platform × feature set matrix looks like in practice, and how to build a validation pipeline that doesn’t consume your entire engineering team.

My Take

My take: The technology is ready — Part 1 covered that. The business case is real at scale. But “at scale” is doing a lot of work in that sentence.

The organizations that will succeed with SONiC at the edge are the ones that treat it as an organizational capability investment, not a cost-cutting exercise. If the only line in your business case is “cheaper switches,” you’re setting yourself up for a painful surprise when the opex bill comes due.

The right framing: SONiC at the edge is a bet on your team’s ability to operate open infrastructure. The hardware savings fund that bet. The payoff is operational flexibility and procurement leverage that compounds over time — but only if you invest in the team and tooling to realize it.

If your organization has the scale, the engineering maturity, and the patience for a multi-year build, the math works. If you’re looking for a quick win on next quarter’s budget, buy Meraki.

SONiC Hits the Access Layer: Why 1G Commodity Switches Change the Math

brett@network-notes.com (Brett Lykins) — Mon, 06 Apr 2026 10:00:00 -0500

For years, the pitch for SONiC went something like this: “It’s what the hyperscalers run.” And that was true — and also the problem. If you weren’t running a spine-leaf fabric at 100G+, SONiC had nothing for you. The hardware didn’t exist at the access layer. No 48-port 1G copper switches. No PoE. Nothing below 25G.

That’s no longer the case.

I currently work on a team deploying SONiC 1G switches into a global network, with a goal to be “vendor of choice” for our internal customers — so I’m not a neutral party here. What I’m seeing firsthand is a market that has shifted faster than most enterprise network teams realize. If you’re managing tens of thousands of network nodes — office buildings, warehouses, retail locations, distribution centers — SONiC should be on your evaluation list.

SONiC in 60 Seconds

If you’re not familiar: SONiC (Software for Open Networking in the Cloud) is an open-source network operating system built on Debian Linux. Microsoft developed it for Azure’s data center network and open-sourced it in 2016. It now lives under the Linux Foundation as the SONiC Foundation.

The key architectural idea is the Switch Abstraction Interface (SAI). SAI sits between SONiC and the switching ASIC, providing a vendor-neutral API. This means the same NOS runs on silicon from Broadcom, Marvell, NVIDIA/Mellanox, and Intel — you pick the hardware, SONiC talks to it through SAI. The NOS itself is containerized: each major function (BGP, LLDP, SNMP, teamd, etc.) runs in its own Docker container, which means you can upgrade individual components without bouncing the whole switch.

For most of its life, SONiC ran exclusively on data center hardware — Broadcom Trident and Tomahawk ASICs in 25G/100G/400G switches. The enterprise access layer was not in scope.

What Changed

Three things happened in 2024–2025 that made SONiC viable at the access layer.

Marvell’s Prestera ASICs got SAI support. This is the big one. Marvell’s Prestera line is the silicon inside most commodity 1G and 2.5G access switches. Once SAI drivers existed for Prestera, SONiC could run on access-layer hardware. Marvell published a blog in October 2024 specifically about Cloud-Managed Enterprise switches powered by SONiC, signaling that this wasn’t a side project.

Hardware vendors shipped product.

Celestica announced four new enterprise access switches in May 2024 — the ES1000, ES1010, ES1050, and EG1050 — with 1GbE and 2.5GbE options, up to 48 ports, PoE support, and SONiC compatibility.
Asterfusion started shipping 48-port 1G PoE+ switches (CX204Y, CX206Y series) on Marvell Prestera with Enterprise SONiC preloaded.
Edgecore expanded its EPS and AS4600 series for enterprise access deployments.

These aren’t prototypes or reference designs — they’re shipping products with purchase orders behind them.

The result: you can now buy a 48-port 1G PoE+ L3 switch with 25G uplinks, running SONiC, from multiple vendors, at a fraction of what a comparable Cisco Catalyst or Arista switch costs. That sentence was not possible two years ago.

The access-layer feature set filled in. MC-LAG, DHCP snooping, and IGMP snooping are available in the commercial SONiC distributions. The SONiC 202505 release added PVST+ and 802.1X/MAB authentication — two features that were blockers for many access-layer deployments. The gap between SONiC and a traditional enterprise NOS feature set is narrowing fast.

Commercial Support Catches Up

Hardware alone doesn’t make a platform viable. The support ecosystem had to catch up, and it has.

The SONiC Foundation now counts 36 member organizations including Arista, who joined as a Premier Member in 2025. As of early 2024, the project had over 4,250 active contributors across 520+ organizations. This isn’t a niche project anymore.

On the commercial support side, enterprises now have real options:

Broadcom Enterprise SONiC Distribution — the most mature commercial offering. Hardened, extended feature set beyond community SONiC, multi-ASIC support, and commercial support contracts. Think of it as the Red Hat to community SONiC’s Fedora.
Dell Enterprise SONiC — built on Broadcom’s distribution, validated on Dell PowerSwitch hardware, with Dell’s 24/7 support organization behind it.
Aviz Certified Community SONiC — launched in late 2025, this is a pre-tested, multi-ASIC distribution based on community SONiC with added bug fixes, telemetry, and 24/7 commercial support.
Asterfusion AsterNOS — a commercial SONiC distribution specifically targeting access-layer and enterprise deployments on Marvell Prestera hardware.

You don’t have to go it alone with raw community SONiC anymore (though you can, if you have the engineering team for it).

The Open NOS Landscape

SONiC isn’t the only open or disaggregated NOS option. Here’s how the alternatives stack up for enterprise access-layer deployments:

	SONiC	DENT OS	Pica8 PICOS	OcNOS
License	Apache 2.0	Open source (LF)	Commercial	Commercial
Origin	Microsoft (2016)	Amazon/LF (2019)	Pica8 (2012)	IP Infusion
Hardware Abstraction	SAI	Linux SwitchDev	Proprietary	Proprietary
Supported ASICs	Broadcom, Marvell, NVIDIA, Intel	Marvell Prestera	Broadcom	Multi-vendor
1G Access Switches	Yes (2024+)	Yes (designed for edge)	Yes	Limited
PoE Support	Yes	Yes	Yes	Varies
Commercial Support	Multiple vendors	Limited	Pica8	IP Infusion
Management Platform	Varies by distro	None	AmpCon	OcNOS Manager
Enterprise Momentum	4,250+ contributors; multiple commercial distros	Small community	Single vendor	Established in SP

A few notes on the alternatives:

DENT OS is the most interesting comparison. Also a Linux Foundation project, DENT was designed from the start for the distributed enterprise edge — retail, campus, remote sites. It uses Linux SwitchDev instead of SAI, which means you configure switches using standard Linux tools (ip, bridge, tc). If you have a team of Linux sysadmins who happen to manage network switches, DENT’s approach is appealing. The tradeoff is a much smaller ecosystem and limited commercial support options. DENT is worth watching, but SONiC has the momentum.

Pica8 PICOS is a commercial disaggregated NOS targeting enterprise campus networks. It runs on Broadcom-based white box hardware, offers a Junos-like CLI with transactional commit-confirm, and includes AmpCon for centralized ZTP and lifecycle management. The tradeoff: it’s not open source, and you’re trading one vendor dependency for another (albeit a cheaper one).

OcNOS from IP Infusion is a mature commercial disaggregated NOS with strong service provider adoption — worth evaluating if you want hardware disaggregation without the open-source model.

A note on Cumulus Linux: Cumulus was the original disaggregated NOS pioneer and deserves credit for proving the model. But NVIDIA’s acquisition fundamentally changed its trajectory. It now runs exclusively on NVIDIA Spectrum ASICs, dropped Broadcom support after the 4.x release line, and as of mid-2025, is no longer available as a standalone image. I’m not including it in the comparison table because it’s not a viable option for new enterprise access-layer deployments. If you’re currently running Cumulus on Broadcom hardware, Pica8 is actively positioning PICOS as a migration path.

When to Evaluate SONiC for Your Access Layer

SONiC makes the most sense when several of these conditions are true:

You have scale. If you’re managing hundreds or thousands of access switches across many sites, the per-unit cost savings on hardware compound fast. One engineer on the Network Automation Forum estimated potential savings of $1.3 million on a single edge upgrade — though the same discussion noted that compensating costs in staffing and operational complexity can eat into those numbers. White box hardware commonly runs at one-half to one-third the cost of branded equivalents from Cisco or Arista.

You have (or can build) the engineering team. SONiC is Linux. Your network engineers need to be comfortable with Debian, systemd, Docker containers, and debugging at the OS level. This is a different skill set than CLI-driven IOS or EOS administration. If your team already treats infrastructure as code and manages config via automation, the transition is smoother than you’d expect. If your team’s workflow is “SSH in and type commands,” you have a culture change ahead of you, not just a technology change.

You want operational consistency across your stack. If you’re already running SONiC in your data center (or plan to), extending it to the access layer means one NOS, one automation framework, one monitoring pipeline, one set of operational procedures from spine to access port. That operational simplification has real value at scale.

You’re tired of vendor lock-in. With SONiC, you can swap hardware vendors without changing your NOS, your automation, or your operational tooling. If Celestica has a better price on 48-port switches this quarter but Edgecore wins next quarter, you can mix and match.

When to Stay Away

You need plug-and-play simplicity. If your network team is small, your sites are few, and you need something that works out of the box with a GUI and phone support, buy Meraki or Aruba. SONiC will cost you more in engineering time than you’ll save on hardware.

You need mature wireless integration. SONiC is a wired switching NOS. It doesn’t manage access points, and there’s no equivalent to Cisco’s wireless controller integration or Arista’s CloudVision for converged wired/wireless management. You’ll need a separate wireless solution and the operational overhead that comes with it.

Your organization can’t tolerate risk on network infrastructure. Community SONiC has real rough edges — unstable build pipelines, inconsistent platform testing across releases, and gaps in management tooling compared to mature commercial platforms. The commercial distributions smooth this out significantly, but even Enterprise SONiC is younger and less battle-tested at the access layer than IOS-XE or EOS. If your business requires five-nines uptime guarantees with vendor accountability, the commercial SONiC distributions are getting there, but you should evaluate carefully.

The Trajectory

The direction is clear. ONUG reported in early 2025 that SONiC is increasingly deployed in enterprise verticals like telco and financial services, and Aviz Networks CEO Vishal Shukla noted that “since 2023, SONiC enterprise deployment has shifted from early adopters to large, mainstream enterprises.”

The 1G access-layer hardware availability is the inflection point. SONiC’s value proposition was always strong at the data center layer — the economics made sense when you’re buying 100G switches at scale. But most enterprise network ports are 1G copper at the access layer. That’s where the volume is. That’s where the spend is. And now that’s where SONiC runs.

The organizations that will benefit most are the ones with enough scale to justify the engineering investment and enough sites to make the hardware savings meaningful.

My take: The “SONiC is only for hyperscalers” era is over. The hardware gap at the access layer — the thing that kept SONiC out of most enterprise conversations — closed in 2024. If you’re running tens of thousands of switch ports across a global footprint, the math works, the hardware exists, and the support ecosystem is real. The learning curve is steep and the cultural shift is significant, but for organizations with the scale and engineering maturity to make the investment, the economics speak for themselves.

In Part 2, I dig into the business case — what the real costs look like beyond the BOM, when the math works, and how to build a case that doesn’t fall apart when the opex bill comes due.

Testing ISAKMP Part 4: Using Scapy

brett@network-notes.com (Brett Lykins) — Sun, 22 Feb 2026 10:59:00 -0500

In Part 2, I showed how to test ISAKMP with a pre-built hex string and netcat. In Part 3, we dove deep into the byte-by-byte construction of ISAKMP packets. Now let’s use Scapy to automate this with Python.

Why Scapy?

Netcat with hex strings works for one-off tests, but Scapy lets you build packets programmatically, parse responses automatically, and script tests across multiple targets. It understands ISAKMP structure and handles length fields and checksums for you.

Prerequisites

Python 3.8+ installed
Basic Python knowledge
Understanding of ISAKMP concepts (see Part 1)
Target ISAKMP/IKE peer to test
Root/sudo access (required for raw socket operations)

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Install Poetry (if not already installed)
curl -sSL https://install.python-poetry.org | python3 -

# Install Scapy via Poetry
cd /path/to/your/project
poetry init
poetry add scapy

# Or install globally
pip install scapy

# Verify installation
python3 -c "from scapy.all import *; print(conf.version)"

Important: Scapy requires raw socket access, which needs root/sudo privileges. When using Poetry with sudo, you must install dependencies as root: sudo poetry install

Basic ISAKMP Packet with Scapy

The Simple Approach

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


#!/usr/bin/env python3
from scapy.all import *

# Target configuration
target_ip = "192.168.1.1"
target_port = 500

# Build basic ISAKMP packet
# Create IP and UDP layers
ip = IP(dst=target_ip)
udp = UDP(sport=500, dport=target_port)

# Create ISAKMP header (Identity Protection, Main Mode)
isakmp = ISAKMP(
 init_cookie=RandString(8), # Random 8-byte initiator cookie
 resp_cookie=b'\x00' * 8, # Responder cookie (zeros for initial packet)
 exch_type=2, # Identity Protection (Main Mode)
)

# Create SA payload with a simple transform
sa = ISAKMP_payload_SA(
 prop=ISAKMP_payload_Proposal(
 proto=1, # ISAKMP
 trans=ISAKMP_payload_Transform(
 transform_id=1 # KEY_IKE
 )
 )
)

# Assemble the complete packet
packet = ip / udp / isakmp / sa

# Send and receive
response = sr1(packet, timeout=5, verbose=1)

if response:
 response.show()
else:
 print("No response received")

Building a Complete Phase 1 Packet

Transform Set Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# Define transform set parameters
# Using modern cryptographic standards

# Encryption algorithms (RFC 3602, RFC 2409)
ENCR_AES_CBC = 7
ENCR_3DES_CBC = 5

# Hash algorithms (RFC 2409)
HASH_SHA256 = 4
HASH_SHA1 = 2

# Diffie-Hellman groups (RFC 2409, RFC 3526)
DH_GROUP_14 = 14 # 2048-bit MODP
DH_GROUP_5 = 5 # 1536-bit MODP
DH_GROUP_2 = 2 # 1024-bit MODP

# Authentication methods (RFC 2409)
AUTH_PSK = 1 # Pre-Shared Key
AUTH_RSA_SIG = 3 # RSA Signatures

# Life duration type (RFC 2409)
LIFE_TYPE_SECONDS = 1
LIFE_TYPE_KILOBYTES = 2

# Define a modern transform set
transform_set = {
 'encryption': ENCR_AES_CBC,
 'key_length': 256, # AES-256
 'hash': HASH_SHA256,
 'dh_group': DH_GROUP_14,
 'auth_method': AUTH_PSK,
 'lifetime': 86400 # 24 hours in seconds
}

Constructing the Packet

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


from scapy.all import *

def build_isakmp_packet(target_ip, transform_set):
 """
 Build a complete ISAKMP Phase 1 Main Mode packet with specified transform set.

 Args:
 target_ip: Target IP address
 transform_set: Dictionary with encryption, hash, dh_group, auth_method, lifetime

 Returns:
 Complete Scapy packet ready to send
 """
 # IP and UDP layers
 ip = IP(dst=target_ip)
 udp = UDP(sport=500, dport=500)

 # ISAKMP header
 isakmp = ISAKMP(
 init_cookie=RandString(8),
 resp_cookie=b'\x00' * 8,
 exch_type=2, # Identity Protection (Main Mode)
 )

 # Build transform attributes as list of (type, value) tuples
 # Type numbers: 1=Encryption, 2=Hash, 3=Auth, 4=Group, 11=LifeType, 12=LifeDuration, 14=KeyLength
 transforms = [
 (1, transform_set['encryption']), # Encryption algorithm
 (2, transform_set['hash']), # Hash algorithm
 (4, transform_set['dh_group']), # DH Group
 (3, transform_set['auth_method']), # Authentication method
 (11, 1), # Life Type: seconds
 (12, transform_set['lifetime']) # Life Duration
 ]

 # Add key length if specified
 if transform_set.get('key_length', 0) > 0:
 transforms.insert(1, (14, transform_set['key_length']))

 # Build Transform payload
 transform = ISAKMP_payload_Transform(
 transform_id=1, # KEY_IKE
 transforms=transforms
 )

 # Build Proposal payload
 proposal = ISAKMP_payload_Proposal(
 proposal=1,
 proto=1, # ISAKMP
 trans=transform
 )

 # Build SA payload
 sa = ISAKMP_payload_SA(
 doi=1, # IPsec DOI (lowercase field name)
 situation=1, # Identity Only
 prop=proposal
 )

 # Assemble complete packet
 packet = ip / udp / isakmp / sa

 return packet

# Example usage
target = "192.168.1.1"
packet = build_isakmp_packet(target, transform_set)

Note: Scapy’s ISAKMP implementation uses a list of (type, value) tuples for transform attributes, not individual attribute objects. This is simpler and matches how the protocol actually works.

Sending and Analyzing Responses

Send the Packet

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


def send_isakmp_packet(packet, timeout=5):
 """
 Send ISAKMP packet and capture response.

 Args:
 packet: Scapy packet to send
 timeout: Response timeout in seconds

 Returns:
 Response packet or None
 """
 print(f"[*] Sending ISAKMP packet to {packet[IP].dst}:500")
 print(f"[*] Initiator Cookie: {packet[ISAKMP].init_cookie.hex()}")

 # Send packet and wait for response
 response = sr1(packet, timeout=timeout, verbose=0)

 if response:
 print(f"[+] Response received from {response[IP].src}")
 return response
 else:
 print("[-] No response received (timeout)")
 return None

# Send the packet
response = send_isakmp_packet(packet)

if response and response.haslayer(ISAKMP):
 # Extract basic info
 print(f"\n[*] Response Details:")
 print(f" Responder Cookie: {response[ISAKMP].resp_cookie.hex()}")
 print(f" Exchange Type: {response[ISAKMP].exch_type}")
 print(f" Next Payload: {response[ISAKMP].next_payload}")

 # Check if SA payload is present
 if response.haslayer(ISAKMP_payload_SA):
 print(f"[+] SA payload received - transform set accepted!")
 else:
 print(f"[-] No SA payload - transform set rejected")
 # Note: Some devices send NOTIFY payloads on rejection
 # Check for ISAKMP_payload_Notification for detailed error info

Understanding the Response

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


def parse_isakmp_response(response):
 """
 Parse ISAKMP response and extract transform set details.

 Args:
 response: Scapy packet containing ISAKMP response

 Returns:
 Dictionary with parsed response details
 """
 if not response or not response.haslayer(ISAKMP):
 return None

 result = {
 'responder_cookie': response[ISAKMP].resp_cookie.hex(),
 'exchange_type': response[ISAKMP].exch_type,
 'accepted': False,
 'transform_set': {}
 }

 # Check for SA payload (indicates acceptance)
 if response.haslayer(ISAKMP_payload_SA):
 result['accepted'] = True

 # Extract transform attributes if present
 if response.haslayer(ISAKMP_payload_Transform):
 transform = response[ISAKMP_payload_Transform]

 # Parse attributes
 if hasattr(transform, 'attributes'):
 for attr in transform.attributes:
 attr_type = attr.attribute_type
 attr_val = attr.attribute_value

 # Map attribute types to names
 if attr_type in [0x8001, 0x0001]:
 result['transform_set']['encryption'] = attr_val
 elif attr_type in [0x800e, 0x000e]:
 result['transform_set']['key_length'] = attr_val
 elif attr_type in [0x8002, 0x0002]:
 result['transform_set']['hash'] = attr_val
 elif attr_type in [0x8004, 0x0004]:
 result['transform_set']['dh_group'] = attr_val
 elif attr_type in [0x8003, 0x0003]:
 result['transform_set']['auth_method'] = attr_val

 return result

# Example usage
if response:
 parsed = parse_isakmp_response(response)

 if parsed and parsed['accepted']:
 print("\n[+] Transform set ACCEPTED by peer")
 print(f" Encryption: {parsed['transform_set'].get('encryption', 'N/A')}")
 print(f" Hash: {parsed['transform_set'].get('hash', 'N/A')}")
 print(f" DH Group: {parsed['transform_set'].get('dh_group', 'N/A')}")
 else:
 print("\n[-] Transform set REJECTED or no response")

Advanced Usage

Testing Multiple Transform Sets

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73


def test_transform_sets(target_ip, transform_sets, timeout=5):
 """
 Test multiple transform sets against a target.

 Args:
 target_ip: Target IP address
 transform_sets: List of transform set dictionaries
 timeout: Response timeout in seconds

 Returns:
 List of results with acceptance status
 """
 results = []

 for i, ts in enumerate(transform_sets, 1):
 print(f"\n[*] Testing transform set {i}/{len(transform_sets)}")
 print(f" Encryption: {ts['encryption']}, Hash: {ts['hash']}, DH: {ts['dh_group']}")

 # Build and send packet
 packet = build_isakmp_packet(target_ip, ts)
 response = sr1(packet, timeout=timeout, verbose=0)

 # Parse response
 parsed = parse_isakmp_response(response)

 result = {
 'transform_set': ts,
 'accepted': parsed['accepted'] if parsed else False,
 'response': parsed
 }
 results.append(result)

 if result['accepted']:
 print(f" [+] ACCEPTED")
 else:
 print(f" [-] REJECTED or no response")

 # Small delay between tests
 time.sleep(1)

 return results

# Define multiple transform sets to test
test_sets = [
 # Modern strong crypto
 {
 'encryption': 7, # AES-CBC
 'key_length': 256,
 'hash': 4, # SHA-256
 'dh_group': 14, # 2048-bit
 'auth_method': 1,
 'lifetime': 86400
 },
 # Moderate crypto
 {
 'encryption': 7, # AES-CBC
 'key_length': 128,
 'hash': 4, # SHA-256
 'dh_group': 14, # 2048-bit
 'auth_method': 1,
 'lifetime': 86400
 }
]

# Run tests
results = test_transform_sets("192.168.1.1", test_sets)

# Summary
print("\n" + "="*50)
print("SUMMARY")
print("="*50)
accepted = [r for r in results if r['accepted']]
print(f"Accepted: {len(accepted)}/{len(results)} transform sets")

Aggressive Mode vs Main Mode

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77


def build_aggressive_mode_packet(target_ip, transform_set, identity="test@example.com"):
 """
 Build ISAKMP Aggressive Mode packet.

 Aggressive Mode sends more information in the first packet (including identity)
 but completes the exchange faster (3 packets vs 6 in Main Mode).

 Args:
 target_ip: Target IP address
 transform_set: Transform set dictionary
 identity: Identity string for ID payload

 Returns:
 Complete Scapy packet
 """
 # IP and UDP layers
 ip = IP(dst=target_ip)
 udp = UDP(sport=500, dport=500)

 # ISAKMP header for Aggressive Mode
 isakmp = ISAKMP(
 init_cookie=RandString(8),
 resp_cookie=b'\x00' * 8,
 next_payload=1, # SA payload
 exch_type=4, # Aggressive Mode (vs 2 for Main Mode)
 flags=0
 )

 # Build SA payload (same as Main Mode)
 # ... (use build_isakmp_packet logic for SA/Proposal/Transform)

 # Add Key Exchange payload (sent in first packet in Aggressive Mode)
 ke = ISAKMP_payload_KE(
 next_payload=5, # ID payload follows
 ke=RandString(128) # DH public value (size depends on DH group)
 )

 # Add Identification payload (sent in first packet in Aggressive Mode)
 id_payload = ISAKMP_payload_ID(
 next_payload=0,
 IDtype=3, # ID_USER_FQDN
 IdentData=identity.encode()
 )

 # Assemble: ISAKMP / SA / KE / ID
 # Note: In Main Mode, KE and ID come in later packets
 packet = ip / udp / isakmp / sa / ke / id_payload

 return packet

# Compare the two modes:

# Main Mode (6 packets total, more secure)
# Packet 1: HDR, SA
# Packet 2: HDR, SA
# Packet 3: HDR, KE, Nonce
# Packet 4: HDR, KE, Nonce
# Packet 5: HDR*, ID, HASH
# Packet 6: HDR*, ID, HASH

main_mode_packet = build_isakmp_packet("192.168.1.1", transform_set)
print(f"Main Mode packet size: {len(main_mode_packet)} bytes")
print(f"Main Mode exchange type: {main_mode_packet[ISAKMP].exch_type}")

# Aggressive Mode (3 packets total, faster but exposes identity)
# Packet 1: HDR, SA, KE, Nonce, ID
# Packet 2: HDR, SA, KE, Nonce, ID, HASH
# Packet 3: HDR*, HASH

aggressive_packet = build_aggressive_mode_packet("192.168.1.1", transform_set)
print(f"Aggressive Mode packet size: {len(aggressive_packet)} bytes")
print(f"Aggressive Mode exchange type: {aggressive_packet[ISAKMP].exch_type}")

# Security consideration:
# Main Mode encrypts identity, Aggressive Mode sends it in CLEARTEXT
# This is a critical security vulnerability - attackers can harvest identities
# Use Main Mode unless you have a specific requirement for Aggressive Mode

NAT-T Detection

1
2


# TODO: Add NAT-T vendor ID
# TODO: Test for NAT-T support

Creating a Reusable Script

I’ve created a complete script that combines all these techniques. The full code is in the nn_examples repository.

The repository includes additional transform sets (including legacy crypto) for real-world compatibility testing.

Quick Start

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# Clone the repository
git clone https://github.com/lykinsbd/nn_examples.git
cd nn_examples/isakmp_testing

# Install dependencies with Poetry (both user and root)
poetry install
sudo poetry install

# Test a single target
sudo poetry run python isakmp_tester.py 192.168.1.1

# Test multiple transform sets
sudo poetry run python isakmp_tester.py 192.168.1.1 --test-multiple

# Use Aggressive Mode
sudo poetry run python isakmp_tester.py 192.168.1.1 --aggressive

Why sudo poetry install? Scapy requires raw socket access (root privileges). Since sudo runs in a separate environment, dependencies must be installed both as your user and as root.

Example Output

1
2
3
4
5
6
7


[*] Testing 192.168.1.1
 Mode: Main Mode
 Encryption: 7
 Hash: 4
 DH Group: 14
[+] ACCEPTED - Transform set accepted by peer
 Responder Cookie: a1b2c3d4e5f67890

Self-Contained Testing

The repository also includes isakmp_listener.py - a test responder for testing without a real VPN device:

1
2
3
4
5
6


# Terminal 1: Start the test listener
sudo poetry run python isakmp_listener.py

# Terminal 2: Test against localhost
sudo poetry run python isakmp_tester.py 127.0.0.1
sudo poetry run python isakmp_tester.py 127.0.0.1 --test-multiple

The listener accepts all proposed transform sets and logs packet details. Good for testing the tester script, learning packet structure, and debugging without VPN hardware.

Note: When testing against localhost (127.0.0.1), you may receive ISAKMP responses even without the listener running. This is the kernel’s UDP socket handling, not actual ISAKMP protocol responses. For realistic testing, use a real ISAKMP/VPN device or test between different machines.

Comparison: Scapy vs Netcat vs ike-scan

Feature	Scapy	Netcat	ike-scan
Dynamic construction	✅	❌	✅
Response parsing	✅	❌	✅
Scripting	✅	⚠️	⚠️
Learning tool	✅	✅	❌
Production ready	⚠️	❌	✅
Installation	pip	Built-in	Package manager

Security Considerations

⚠️ Authorization Required: Only test systems you own or have explicit permission to test. ISAKMP probes are logged by VPN concentrators, firewalls, and IDS/IPS systems. Repeated probes trigger security alerts.

Phase 1 Only: This covers IKE Phase 1 (ISAKMP) only. Establishing a full VPN tunnel requires Phase 2 (IPsec Quick Mode) and proper authentication credentials.

Cryptographic Parameters: Use SHA-256 (not SHA-1), AES-256, and DH Group 14+ (2048-bit minimum).

Troubleshooting

Permission Denied

1
2
3
4
5


# Scapy requires root for raw sockets
sudo poetry run python script.py

# Make sure dependencies are installed for root too
sudo poetry install

No Response Received

Check firewall rules (UDP/500)
Verify target IP is correct
Confirm ISAKMP service is running
Check for NAT between you and target
VPN concentrators rate-limit ISAKMP attempts - wait 30-60 seconds between tests

Import Errors

1
2


# Install missing dependencies
pip install scapy cryptography

Next Steps

Explore IKEv2 with Scapy
Build Phase 2 (Quick Mode) packets
Implement full IKE exchange
Add support for certificates (RSA signatures)

Conclusion

Scapy bridges the gap between manual packet construction and specialized tools like ike-scan. While netcat teaches you the raw protocol (Part 2) and manual construction reveals the internals (Part 3), Scapy gives you the power to automate and scale your testing.

For production VPN scanning, use dedicated tools like ike-scan or nmap --script ike-version. For learning and custom testing, Scapy is unmatched.

References

Testing ISAKMP Part 3: Building Packets from Scratch

brett@network-notes.com (Brett Lykins) — Sat, 14 Feb 2026 17:16:00 -0500

In Part 2, I provided a ready-to-use ISAKMP packet for testing VPN connectivity. But where did that hex string come from? This post breaks down ISAKMP packet construction byte-by-byte.

Understanding packet structure at the byte level helps you debug protocol issues, customize packets for specific testing scenarios, and understand what tools like ike-scan are doing under the hood.

The Approach

After spending time reading RFC2408 for the basic header in Part 1, I decided to base this complete packet on an actual captured ISAKMP conversation. If you don’t have an ISAKMP capture handy, you can find protocol details and examples at the Wireshark ISAKMP Protocol page.

I still recommend reading RFC2408 to understand ISAKMP message structure, otherwise this sea of hexadecimal will be confusing.

Hand-Crafted Datagram

The primary ingredient needed to make a complete ISAKMP datagram is an attempt to set up the SA (Security Association) including nested inner payloads and an offer of a Transform set.

As discussed previously, the header format for ISAKMP (IKE v1) is defined in RFC2408 Section 3.1.

Initiator and Responder Cookies
- 8 bytes per Cookie
- Initiator Cookie
  - AKA the SPI or Security Parameter Index
  - We’ll make this a value of 1 since it has to be something and we don’t care what it is.
  - Production note: RFC 2408 recommends pseudo-random generation to prevent DoS attacks
  - \x00\x00\x00\x00\x00\x00\x00\x01
- Responder Cookie
  - All zeros because this is an initial communication, and as the Initiator, we don’t know what the responder will send yet.
  - \x00\x00\x00\x00\x00\x00\x00\x00
Next Payload
- 1 byte
- The Next Payload will be of a Security Association type, so per RFC2408 Section 3.1 this is a value of 1.
- \x01
Major Version and Minor Version
- 4 bits each
- Mandatory values of 1 and 0, because we’re using ISAKMP version 1.0
- That would be 0001 and 0000 in binary.
- Together, that would look like 00010000, which equals 10 in Hex.
- \x10
Exchange Type
- 1 byte
- The Exchange Types are laid out in RFC2408 Section 4.4 to Section 4.8.
- From our sample packet capture, I see we want an Identity Protection type (02).
- \x02
Flags
- 1 byte
- We still need no flags, so leaving this at 0.
- \x00
Message ID
- 4 bytes
- Must be zeros per RFC2408 for an initial Phase 1 datagram like we’re simulating.
- \x00\x00\x00\x00
Length
- 4 bytes
- I have doubled back from the bottom to fill in this value, as you are unable to calculate it until you have built all the inner payloads.
- This totals up to 88 bytes or 58 in hex.
- \x00\x00\x00\x58

Generic Payload Header

There is a short header on each ISAKMP payload as shown below, it is defined in RFC2408 Section 3.2. We’ll need one on our outer SA Payload, and one will be present on any interior/nested payloads as well (such as additional Proposals or Vendor Specific Attributes).

Next Payload
- 1 byte
- This is the last outer payload, so 0.
- We’re not simulating Vendor Specific Attributes or anything like that, just trying to make a minimum viable datagram.
- \x00
RESERVED
- 1 byte
- Unused, set to Zero.
- \x00
Payload Length
- 2 bytes
- I am cheating somewhat, and know this value as I have gone forward to finish the payload, and then calculated backward to get this value.
- It includes the Generic Payload header elements (including the length field we’re calculating now) and the length of the inner SA Payload from below.
- That totals 60 bytes or 3c in hex.
- \x00\x3c

Security Association Payload

SA Payload is defined in RFC2408 Section 3.4 and laid out as shown below.

Domain of Interpretation (DOI)
- 4 bytes
- See RFC2408 Section 2.1 for more information on what the DOI is. For our purposes, this is a value of 1, for an IPSEC DOI (RFC2407).
- \x00\x00\x00\x01
Situation
- Variable length (4 bytes in this case)
- based on the DOI For IPSEC DOI, per RFC2407 section 4.2, this will be 4 bytes.
- Our sample capture indicates to say that this is Identity Only (value of 00000001).
- \x00\x00\x00\x01

Proposal Payload

Inside the SA Payload, there is the payload containing the ISAKMP Proposal on how to go about setting up the Security Association.

Next Payload
- 1 byte
- This will be zero as there is no other Proposal being sent.
- \x00
RESERVED
- 1 byte
- Unused, set to zero.
- \x00
Payload length
- 2 bytes
- Again, I only know this value as I am working backward, and have calculated it out knowing the length of this payload.
- It is 48 bytes long (including the two bytes above, these two bytes, and everything in the payload below), which is 30 in hex.
- \x00\x30
Proposal Number
- 1 byte
- If there is more than one Proposal in the payload, which Proposal is this?
- In our case, this is the first and only Proposal, so set this to 00000001.
- \x01
Protocol ID
- 1 byte
- This took some tracking down, but as defined in RFC2408 Section 3.6, the specific values for these are defined by the DOI in use (IPSec DOI in our case).
- The IDs are defined in RFC2407 Section 4.4.1, and we’re using ISAKMP (value of 1).
- \x01
SPI Size
- 1 byte
- Set to zero for ISAKMP (as the Initiator and Responder cookies will be used for the SPIs).
- \x00
Number of Transforms
- 1 byte
- We’re just sending one Transform, so set it to a value of 1.
- \x01

Transform Payload

And finally, inside of THAT payload are one or more Transforms. (I told you this would get confusing…) For our purposes, I’m just going to offer a single, common transform set consisting of:

Encryption: AES-128
Hash: SHA
Diffie-Hellman: Group 5
Authentication: Pre-Shared Key
Lifetime 86400 seconds

⚠️ Security Notice: This packet uses legacy cryptographic parameters for maximum compatibility with older devices. For production VPNs, use:

Hash: SHA-256 or SHA-384

Encryption: AES-256-CBC or AES-256-GCM

DH Group: Group 14 (2048-bit) or higher

Consider IKEv2 instead of IKEv1 for modern deployments

It is worth noting that the Transform Attributes are expressed as TLV (Type-Length-Value) or TV (Type-Value). If you’re not familiar with what a TLV is, I recommend becoming familiar with it as it crops up again and again in network protocols. TLVs allow a protocol to be extended in ways beyond the original scope, for example, TLVs are what make a routing protocol like ISIS able to be extended to support Shortest Path Bridging.

The TLV/TV information for our purposes is laid out across all three original IPSEC/ISAKMP/IKE RFCs (RFC2407, RFC2408, and RFC2409 respectively.)

For getting the bulk of actual Types, Values, and whether they are fixed or variable length, you need RFC2409 Appendix A which lists the IKE Attribute Assigned Numbers.
RFC2408 Section 3.3 however, specifies the underlying Data Attribute format.
But to figure out what Domain of Interpretation (DOI) to use we have to consult RFC2407 Section 4.4.2.

It is also important to call out that RFC2408 Section 3.3 indicates that the most significant (leftmost) bit of the Attribute field, will determine if these bits represent a TLV (0) or TV (1).

If it is a TLV (0), then there is a length field sent.
If it is a TV (1), then it is assumed to be two bytes, and no length field is sent.

For example, this means that a TV (1) for an Encryption Algorithm (1) of AES-CBC (7) in Binary would be:

1000 0000 0000 0001 0000 0000 0000 0111

Translated to Hexadecimal, that would come out as:

\x80\x01\x00\x07

We will similarly construct each value below (and we’ll use this value as well).

Transform Set

Next Payload
- 1 byte
- This will be zero as no other Transforms are being sent.
- \x00
RESERVED
- 1 byte
- Unused, set to zero.
- \x00
Payload length
- 2 bytes
- This is a value of 40 bytes that I only know because I finished building the payload and came back to calculate this value.
- 40 in hex is 28.
- \x00\x28
Transform Number
- 1 byte
- This is the only transform we’re sending, and it’s the first, so 1.
- \x01
Transform ID
- 1 byte
- This value is specified by the DOI, so RFC2407 Section 4.4.2 says to use 1 for IKE.
- \x01
RESERVED2
- 2 bytes
- Two more bytes of mandatory zeros.
- \x00\x00

Transform IKE Attributes

Encryption Algorithm
- 4 bytes
- As we worked out above, this should be four bytes for a TV (starting with 80).
- Next, comes the encryption algorithm attribute class of 1.
- The attribute class value portion of this TV was a little tricky because AES came out well after RFC2409 was published.
- That information is laid out in RFC3602 (The AES-CBC Cipher Algorithm and Its Use with IPsec) Section 5.1, and indicates that the AES ID is “7”.
- \x80\x01\x00\x07
Key Length
- 4 bytes
- We’re using a Key Length (class attribute of 14, or 0e in hex) of 128 bits (80 in hex), and this is a TV as well, so we get:
- \x80\x0e\x00\x80
Hash Algorithm
- 4 bytes
- We’re using a hash algorithm (class attribute of 2) of SHA (which is also a value of 2), and again we’re getting these values from RFC2409 Appendix A.
- Also, this field is a TV, which means it again starts with \x80 and is 4 bytes, so we have:
- \x80\x02\x00\x02
Diffie-Hellman Group
- 4 bytes
- For the Group Description (class attribute of 4) we’re going to use DH Group 5, which scouring RFC2409 Appendix A again tells us is a value of 5.
- This is again a TV (starts with \x80) and is 4 bytes:
- \x80\x04\x00\x05
Authentication Method
- 4 bytes
- For the Authentication Method (class attribute of 3) we are using a pre-shared key (value of 1):
- \x80\x03\x00\x01
Lifetime
- 4 + variable bytes (8 in this case)
- We’re going to set a lifetime of one day (or 86400 seconds).
- This breaks into two fields.
  - First a TV of Life Type (what are we measuring, seconds or kilobytes) with:
    - A class attribute of 11 (0b in hex) and a value of 1 for seconds.
  - Next is a TLV (which starts with 00 instead of 80) of Life Duration (how many of that unit) with:
    - A class attribute of 12 (0c in hex), a two-byte length field with a value of 4 bytes, and a value of 86400 decimal = 0x15180 hex (written as \x00\x01\x51\x80 in big-endian).
- \x80\x0b\x00\x01\x00\x0c\x00\x04\x00\x01\x51\x80

The Complete Hex String

Now to add all of this into one giant string of hexadecimal:

1

\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x01\x10\x02\x00\x00\x00\x00\x00\x00\x00\x00\x58\x00\x00\x00\x3c\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x30\x01\x01\x00\x01\x00\x00\x00\x28\x01\x01\x00\x00\x80\x01\x00\x07\x80\x0e\x00\x80\x80\x02\x00\x02\x80\x04\x00\x05\x80\x03\x00\x01\x80\x0b\x00\x01\x00\x0c\x00\x04\x00\x01\x51\x80

This 88-byte packet represents a complete ISAKMP Phase 1 Identity Protection exchange initiation with the transform set we defined above.

Conclusion

Building ISAKMP packets byte-by-byte is tedious but educational. It gives you deep insight into how VPN protocols work at the wire level. For practical testing, use the ready-made packet from Part 2 or tools like ike-scan.

Key Takeaways:

ISAKMP packets have nested payload structures (SA → Proposal → Transform)
Each payload has its own header with length fields
Transform attributes use TLV/TV encoding
Length fields must be calculated backward from inner payloads
Understanding this structure helps debug VPN issues

For those interested in automating this process, consider exploring Python with the Scapy library for dynamic packet construction.

Testing ISAKMP Part 2: Pre-Built Packets

brett@network-notes.com (Brett Lykins) — Sat, 07 Feb 2026 10:00:00 -0500

In my previous post about using netcat to test ISAKMP, I validated that UDP/500 was open to the destination, and that semi-valid ISAKMP headers were being received by the peer (a Cisco ASAv in this case). However, this validation required me to be knowledgeable in troubleshooting the Cisco ASA platform so that I could determine if my pseudo-ISAKMP packets arrived (and also required that I control or have access to the ASA). What if the peer is outside of your control or is a platform you are not at all familiar with? In that case, what I want to do now is send a complete ISAKMP initial communication and receive a reply from the peer. This test serves the dual purpose of removing the need for debugs or logging on the peer and validates the return path (and any stateful/L7 inspection) as well.

Rather than hand-crafting every byte again, I based this packet on an actual captured ISAKMP conversation. If you don’t have a capture handy, you can find ISAKMP protocol details and examples at the Wireshark ISAKMP Protocol page.

Want to understand how this packet was built? Check out Part 3 for a detailed byte-by-byte breakdown of ISAKMP packet construction.

The Test Packet

I’ve constructed a complete 88-byte ISAKMP Phase 1 packet with the following transform set:

Encryption: AES-128-CBC
Hash: SHA-1
DH Group: Group 5 (1536-bit MODP)
Authentication: Pre-Shared Key
Lifetime: 86400 seconds (24 hours)

⚠️ Security Notice: This packet uses legacy cryptographic parameters for maximum compatibility with older devices. For production VPNs, use:

Hash: SHA-256 or SHA-384

Encryption: AES-256-CBC or AES-256-GCM

DH Group: Group 14 (2048-bit) or higher

Consider IKEv2 instead of IKEv1 for modern deployments

Quick Reference

For those who want to skip the detailed explanation and just test connectivity, here’s everything you need:

Complete ISAKMP Test Packet:

1

ISAKMP_PACKET="\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x01\x10\x02\x00\x00\x00\x00\x00\x00\x00\x00\x58\x00\x00\x00\x3c\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x30\x01\x01\x00\x01\x00\x00\x00\x28\x01\x01\x00\x00\x80\x01\x00\x07\x80\x0e\x00\x80\x80\x02\x00\x02\x80\x04\x00\x05\x80\x03\x00\x01\x80\x0b\x00\x01\x00\x0c\x00\x04\x00\x01\x51\x80"

Basic Test:

1

echo -ne "$ISAKMP_PACKET" | nc -u TARGET_IP 500

With Timeout and Response Capture:

1

echo -ne "$ISAKMP_PACKET" | timeout 5 nc -u TARGET_IP 500 | hexdump -C

What This Packet Offers:

Encryption: AES-128-CBC
Hash: SHA-1
DH Group: Group 5 (1536-bit MODP)
Authentication: Pre-Shared Key
Lifetime: 86400 seconds (24 hours)

Testing the Complete Datagram

Now that we have our complete ISAKMP packet, let’s test it with netcat. The beauty of this approach is that we’ll get a proper ISAKMP response back if the peer is functioning correctly, eliminating the need for debug access.

Basic Test

1

echo -ne "$ISAKMP_PACKET" | nc -u 192.168.1.1 500

Enhanced Test with Timeout

For better control and to avoid hanging connections, use netcat with a timeout:

1

echo -ne "$ISAKMP_PACKET" | timeout 5 nc -u 192.168.1.1 500

Capturing the Response

To see the hex response for analysis:

1

echo -ne "$ISAKMP_PACKET" | timeout 5 nc -u 192.168.1.1 500 | hexdump -C

Expected Results

Analyzing the Response

When you receive a response, here’s how to decode it:

Bytes 0-7 (Initiator Cookie):

1

00 00 00 00 00 00 00 01

Should match YOUR initiator cookie - confirms this is a reply to your packet.

Bytes 8-15 (Responder Cookie):

1

a1 b2 c3 d4 e5 f6 07 08

Non-zero random value - the peer’s SPI. Save this for multi-packet exchanges.

Byte 16 (Next Payload):

01 = SA payload (peer accepted and is proposing parameters)
0d = Notification payload (usually an error)

Byte 18 (Exchange Type):

02 = Identity Protection (Main Mode) - normal
05 = Informational - usually error notification

Bytes 24-27 (Length):

1

00 00 00 84

Total packet length (132 bytes). Longer responses typically mean successful negotiation.

Common Notification Payloads:

0e 00 (14) = NO-PROPOSAL-CHOSEN - transform set mismatch
18 00 (24) = AUTHENTICATION-FAILED - PSK/cert issue
0d 00 (13) = INVALID-PAYLOAD-TYPE - malformed packet

Successful Response

If the ISAKMP peer is functioning correctly, you should receive a response that:

Has the same initiator cookie (00 00 00 00 00 00 00 01) in the first 8 bytes
Contains a responder cookie (non-zero values in bytes 9-16)
Shows exchange type 02 (Identity Protection) in byte 18
Has a reasonable length (typically 100+ bytes for a full SA response)

Example successful response header:

1
2


00000000 00 00 00 00 00 00 00 01 a1 b2 c3 d4 e5 f6 07 08 |................|
00000010 01 10 02 00 00 00 00 00 00 00 00 84 |............|

Error Responses

Different error conditions will produce different responses:

No Matching Transform Sets:

You’ll get a response with a Notification payload
The notification will indicate “NO-PROPOSAL-CHOSEN” (error 14)

Authentication Issues:

May receive “AUTHENTICATION-FAILED” notification
Or connection may be silently dropped

Firewall/NAT Issues:

No response at all (timeout)
Or ICMP unreachable messages

Troubleshooting Tips

No Response

Check basic connectivity first with a basic UDP test
Verify the target IP is actually running ISAKMP/IKE
Check for NAT/firewall blocking UDP/500
Try different source ports - some firewalls are picky
Wait between attempts - rate limiting may block rapid tests (30-60 seconds)

Malformed Packet Errors

Double-check the hex string - any typos will break the packet
Verify packet length matches the length field in the header
Test with Wireshark to validate packet structure

Transform Set Mismatches

Try different encryption algorithms (3DES, AES-256)
Adjust DH groups (Group 2, Group 14)
Change hash algorithms (MD5, SHA-256)

NAT Considerations

NAT Detection: If testing through NAT, be aware:

Source port randomization may break return traffic
Some firewalls require NAT-T (UDP 4500) for NATed ISAKMP
ESP (protocol 50) will be blocked by NAT without NAT-T

Testing through NAT:

1
2


# Bind to specific source port
echo -ne "$ISAKMP_PACKET" | nc -u -p 500 TARGET_IP 500

NAT-T Detection: Modern VPN gateways may respond on UDP 4500 instead of 500 if NAT is detected.

Aggressive Mode vs Main Mode

This packet uses Main Mode (Identity Protection). If you get no response, the peer might only support Aggressive Mode:

Change Exchange Type from \x02 to \x04 (byte 18)
Note: Aggressive Mode is deprecated due to security weaknesses

IKEv2 Confusion

If you get INVALID_MAJOR_VERSION notification:

Target only supports IKEv2 (RFC 7296)
This technique only works for IKEv1
Use ike-scan tool for IKEv2 testing

Validating Your Packet

Before testing against production systems, validate your packet structure:

1
2
3


# Capture your test packet
echo -ne "$ISAKMP_PACKET" | nc -u 127.0.0.1 500 &
sudo tcpdump -i lo -w test.pcap udp port 500

Open in Wireshark and verify:

ISAKMP protocol is correctly decoded (not “Malformed Packet”)
All payload lengths match actual payload sizes
Transform attributes are properly formatted
No “Expert Info” warnings about malformed fields

Alternative Tools

While this manual method teaches protocol internals, consider these tools for production use:

ike-scan:

1

ike-scan -M TARGET_IP

Supports IKEv1 and IKEv2
Tests multiple transform sets automatically
Better for production troubleshooting

nmap:

1

nmap -sU -p 500 --script ike-version TARGET_IP

Detects IKE version support
Identifies vendor implementations

When to use manual method:

Learning protocol internals
Highly restricted environments (no tools available)
Testing specific edge cases
Forensic analysis of VPN behavior

Conclusion

By using a pre-crafted complete ISAKMP datagram, we’ve eliminated the dependency on having debug access to the peer device. This approach validates outbound connectivity (UDP/500 reachability), peer responsiveness, and return path functionality - all without needing access to the remote device.

For a detailed breakdown of how this packet was constructed, see Part 3. For automated testing with Python and Scapy, check out Part 4.

References

Next Steps:

Want to understand how this packet was built? Read Part 3
Explore automating this with Python and the Scapy library
Check out ike-scan for more advanced VPN testing scenarios

Parsing Network Device Output Part 3: CiscoConfParse

brett@network-notes.com (Brett Lykins) — Mon, 19 Jan 2026 10:55:00 -0500

In the first post in this series, I talked briefly about utilizing Regular Expressions (Regex) to parse network device output. Next, I delved into the difference between status and configuration for network device output, and why you might use one tool vs another depending on which type of output you are working with.

As a brief refresher, network device output (from a traditional CLI session) can generally come in two forms:

Status
- An output that presents some attribute or information about the current state of the device or its performance.
- Example commands for gathering status include:
  - show version
  - show interfaces
- Example commands for modifying status include:
  - clear counters
  - reload
Configuration
- An output that presents the desired/requested operating condition of the device.
- Example commands for gathering configuration include:
  - show running-config
  - show startup-config

In this post, we’ll look at one of the open-source parsing libraries that exist for network device configuration: CiscoConfParse.

Why Not Just Use Regex?

CiscoConfParse, as well as Hierarchical Configuration (heir_config) which we’ll cover in the next post, provide much more power than using Regex alone to match and extract a pattern from a line of status or configuration. These parsing libraries provide a framework to understand and manipulate “Cisco style” configuration (with indented blocks representing related items), or even “Juniper style” curly brace ({}) delineated configuration.

If you think about the previous Regex example, how would we utilize Regex to parse the following configuration output, specifically looking to answer this question:

What interfaces have security-level 0 configured on them?

!
interface GigabitEthernet0/0
description OUTSIDE-VLAN300-10.10.10.0/24
nameif OUTSIDE
security-level 0
ip address 10.10.10.50 255.255.255.0
!
interface GigabitEthernet0/1
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/1.400
description INSIDE-VLAN400-10.10.40.0/24
vlan 400
nameif INSIDE
security-level 100
ip address 10.10.40.1 255.255.255.0
!
interface Management0/0
management-only
nameif MGMT
security-level 0
ip address 10.10.60.2 255.255.255.0

For example, you can certainly search for the string “security-level 0”, however how do you then tie it back to the interface above it? Remember that when we’re evaluating a string with Regex, we can work on a multi-line string. We would have to set up capturing groups for the interface and nameif, and then only match if there was also our target string. And while this is doable, it quickly becomes cumbersome to do for every item you wish to match. Also consider, what if you want to output the entire interface configuration for any interface that matches “security-level 0”? There is a better and simpler way to handle this.

Enter CiscoConfParse

CiscoConfParse solves this problem, and more, by breaking the configuration into parent/child chunks and allowing you to search and find based on the contents of either. For an in-depth walk-through and examples I highly recommend the CiscoConfParse documentation; below we’ll demonstrate a quick use case.

For our test environment, we’re utilizing the same firewall pair and management station from the previous post:

In this series of posts, we’ll just use the network shown here. There is a Management Station with Python 3.8 installed, and two Cisco ASAv firewalls (ASAv1 and ASAv2) in a tiered setup.

Code samples and requirements.txt for this post can be found on my Github.

Below is an example script, based on the previous examples in this series, where we log into these ASAs, gather the output of show run interface, and print out the interface(s) with security-level 0 configured.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


#!/usr/bin/env python3

"""
Example code for Network-Notes.com entry on Parsing Network Device Output
"""

import getpass
import sys


from ciscoconfparse import CiscoConfParse
from netmiko import ConnectHandler


"""
Test parsing network device configuration
"""

# Gather the needed credentials
net_device_username = input("Username: ")
net_device_password = getpass.getpass()
# Set enable/secret = password for now
net_device_secret = net_device_password

# Setup a dict with our ASAvs in it, in real world this could be read
# from a CSV or the CLI or any other source
firewalls = {
 "ASAv1": {"ip": "10.10.10.50", "platform": "cisco_asa"},
 "ASAv2": {"ip": "10.10.60.2", "platform": "cisco_asa"},
}

# Setup an empty dict for our results:
results = {}

# Instantiate netmiko connection objects and gather the output of
# `show run interface` on these two firewalls
for fw_name, fw_data in firewalls.items():
 print(f"Connecting to {fw_name}...")
 fw_connection = ConnectHandler(
 ip=fw_data["ip"],
 device_type=fw_data["platform"],
 username=net_device_username,
 password=net_device_password,
 secret=net_device_secret,
 )
 results[fw_name] = fw_connection.send_command(
 command_string="show run interface"
 )

# Parse our results:
print("Parsing Results...")
outside_interfaces = {}
for fw_name, config in results.items():
 interface_config = CiscoConfParse(config=config.splitlines())
 outside_interfaces[fw_name] = interface_config.find_objects_w_child(
 parentspec=r"^interface", childspec="security-level 0"
 )

# Print our results
for fw_name, interface_list in outside_interfaces.items():
 print(f"==== ==== [ {fw_name} \"Outside\" interfaces ] ==== ====\n")
 for interface in interface_list:
 print(f" ==== [ {interface.text} ] ==== \n")
 for line in interface.ioscfg:
 print(f"{line}")
 print("\n")

It will produce the following output when executed:

Username: cisco
Password:
Connecting to ASAv1â€¦
Connecting to ASAv2â€¦
Parsing Resultsâ€¦
==== ==== [ ASAv1 "Outside" interfaces ] ==== ====
==== [ interface GigabitEthernet0/0 ] ====
interface GigabitEthernet0/0
description OUTSIDE-VLAN300-10.10.10.0/24
nameif OUTSIDE
security-level 0
ip address 10.10.10.50 255.255.255.0
ospf authentication-key
ospf message-digest-key 1 md5
ospf authentication message-digest
==== ==== [ ASAv2 "Outside" interfaces ] ==== ====
==== [ interface Management0/0 ] ====
interface Management0/0
management-only
nameif MGMT
security-level 0
ip address 10.10.60.2 255.255.255.0

As you can see, we found the interfaces we needed, and have the entire configuration. Now let’s break apart what happened a little bit more.

Parent/Child Relationships

CiscoConfParse understands the hierarchical nature of Cisco-style configuration. In our example:

Parent: interface GigabitEthernet0/0
Children: All indented lines under that interface (description, nameif, security-level, etc.)

The key method in our script is:

1
2
3


interface_config.find_objects_w_child(
 parentspec=r"^interface", childspec="security-level 0"
)

This searches for:

parentspec: Lines matching regex ^interface (lines starting with “interface”)
childspec: That have a child line containing “security-level 0”

The result is a list of IOSCfgLine objects representing matching parent interfaces.

Key CiscoConfParse Methods

find_objects() - Find lines matching a regex pattern
find_objects_w_child() - Find parents with specific children
find_objects_wo_child() - Find parents without specific children
find_children() - Find all children of a parent

Each object provides:

.text - The configuration line text
.ioscfg - Complete configuration block (parent + children)
.children - List of child objects

Why This Matters

Compare this to the regex approach from Part 1. To find interfaces with security-level 0 using regex, you’d need complex multi-line patterns and capturing groups. CiscoConfParse makes it intuitive by understanding configuration structure.

This works well for:

Security audits (find interfaces with specific settings)
Configuration validation (ensure required settings exist)
Bulk changes (identify what needs updating)

What’s Next

In the next post, we’ll explore Hierarchical Configuration (hier_config), which builds on these concepts to provide configuration comparison and remediation capabilities.

Conclusion

CiscoConfParse transforms configuration parsing from complex regex gymnastics into readable, maintainable code. By understanding parent/child relationships in network configurations, it makes complex parsing tasks manageable.

Migrating from WordPress to Hugo on Cloudflare Pages

brett@network-notes.com (Brett Lykins) — Tue, 11 Jul 2023 13:42:23 -0400

After years of running WordPress on a self-hosted DigitalOcean droplet, I decided it was time for a change. The site was slow, required constant maintenance, and felt like overkill for a personal blog. Here’s how I migrated to Hugo and Cloudflare Pages.

The Old Setup

My previous infrastructure:

Hosting: DigitalOcean droplet ($12/month)
CMS: Self-hosted WordPress with MySQL
CDN: Cloudflare (free tier) in front
Maintenance: Regular updates, security patches, backups
Performance: Decent, but database queries added latency

The droplet ran Ubuntu with Apache, PHP, MySQL, and all the typical WordPress stack. It worked, but it felt heavy for what was essentially a collection of markdown-style posts.

Why Hugo?

I wanted something:

Fast: Static sites are blazing fast
Minimal: No database, no PHP, just HTML/CSS/JS
Portable: Content in markdown, straightforward to version control
Free: Cloudflare Pages offers free hosting
Secure: No CMS to hack, no database to compromise

Hugo checked all these boxes. It’s a static site generator written in Go that’s incredibly fast and has a great ecosystem of themes.

The Migration Process

1. Export WordPress Content

I used the built-in WordPress export tool to generate an XML file with all posts, then converted them to markdown format. Several tools exist for this conversion, including wordpress-to-hugo-exporter and various online converters. Manual cleanup was necessary afterward to fix formatting inconsistencies.

2. Choose a Theme

I selected the Terminal theme for its clean, minimal design. The retro terminal aesthetic fits well with technical content and provides excellent readability.

3. Set Up Hugo Locally

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Install Hugo
brew install hugo

# Create new site
hugo new site network-notes.com
cd network-notes.com

# Add theme
git submodule add https://github.com/panr/hugo-theme-terminal.git themes/terminal

# Configure
cp themes/terminal/exampleSite/config.toml .
# Edit config.toml with my settings

4. Migrate Content

I moved all the converted markdown files into content/posts/ organized by year:

1
2
3
4
5


content/
└── posts/
 ├── 2015/
 ├── 2016/
 └── 2020/

Each post needed some cleanup - fixing image paths, updating internal links, and adjusting frontmatter.

5. Set Up Cloudflare Pages

Cloudflare Pages is straightforward:

Push Hugo site to GitHub
Connect GitHub repo to Cloudflare Pages
Configure build settings:
- Build command: hugo
- Build output directory: public
- Environment variable: HUGO_VERSION=0.120.0

That’s it. Every push to main triggers a new build and deployment.

6. Configure DNS

Updated my Cloudflare DNS to point to Pages:

1

network-notes.com → CNAME → network-notes-com.pages.dev (proxied)

I also set up a preview branch:

1

blog2.network-notes.com → CNAME → preview.network-notes-com.pages.dev (proxied)

This lets me review posts before publishing to production.

7. Decommission DigitalOcean

Once everything was working, I:

Backed up the WordPress database (just in case)
Took a final snapshot of the droplet
Destroyed the droplet
Saved $12/month

The Results

Performance: Page load times dropped from ~800ms to ~200ms. Static HTML is fast.

Maintenance: Zero. No more WordPress updates, no more security patches, no more database backups.

Cost: $0/month for hosting (Cloudflare Pages free tier is generous)

Workflow: Write in markdown, commit to git, automatic deployment. Much better than the WordPress editor.

Reliability: Cloudflare’s global CDN means the site is fast everywhere and has excellent uptime.

Infrastructure as Code

I manage all my DNS and Cloudflare configuration with Terraform. The network-notes.com configuration includes:

DNS records
Page rules for caching
SSL/TLS settings
Preview branch setup

Everything is version controlled and reproducible, making it straightforward to recreate or modify the infrastructure.

Lessons Learned

Markdown is powerful: Once you get used to writing in markdown, it’s hard to go back to WYSIWYG editors.

Static sites aren’t limiting: For a blog, you don’t need dynamic content. Comments can be handled by external services if needed.

Git-based workflows are great: Having your entire site in version control is liberating. Rollbacks are trivial, history is preserved, and collaboration is straightforward.

Cloudflare Pages is excellent: The free tier is generous, builds are fast, and the preview deployments are incredibly useful.

Absolutely, if you’re running a personal blog or documentation site. The migration took a weekend, but the ongoing benefits are worth it:

No more server maintenance
Faster site
Better workflow
Lower costs
More secure

If you need dynamic features (user accounts, complex forms, e-commerce), WordPress or another CMS might still make sense. But for content-focused sites, static site generators like Hugo are hard to beat.

Resources

The blog is now faster, cheaper, and easier to maintain. Sometimes simpler really is better.

Parsing Network Device Output Part 2: Status or Configuration?

brett@network-notes.com (Brett Lykins) — Sat, 21 Mar 2020 20:01:00 -0500

A Brief Interlude

In my first post in this series, I dove into utilizing Regular Expressions (Regex) to parse network device output. Before I continue with some of the other parsing options, I thought it would be worthwhile to post a short blog laying out some definitions that I’ll be relying on. Specifically, I’ll be using them for delineation among the different parsing options and their use cases.

At the heart of this problem, is that when interacting with traditional network devices there aren’t many programmatic options, such as a REST API, to return structured data. Sure, you could use SNMP for some things, but not for everything. In addition, working with SNMP can be its type of nightmare, believe me, I’ve fought that fight many times in the past. This is changing as the industry matures, Cisco even has an entire certification track around utilizing their APIs now, however even today most Network Engineers’ first foray into automation uses SSH to query a device for information. This brings us to output.

What is Output?

For our purposes, “Output” will be defined as any response that a network device returns when given a command via its Command Line Interface (CLI). This could be accomplished by many means; depending on the network device in question the CLI could be reached via Telnet, SSH, or even HTTPS. No matter the access method, the network device is still returning the same data, our output.

Execute show version on a Cisco-like device, and it will return some form of the status of the version as that device understands it. It will be structured, loosely, for human consumption with perhaps headings/titles or indentation/punctuation for legibility. It will not generally be structured in a way that would easily allow a computer program to understand and interact with it.

Just as you can issue show version and get output, you can similarly on most network devices execute a command akin to show running-config and get output. This would return some form of data about the configuration that was currently in use on that network device. Again, it will have some form of structure, usually either delineated by indentation or curly braces ({}), but mostly it will be in a form that is not easily understood or manipulated by a computer program that you are writing.

I make the specific call out that it may not easily be understood by a program that you are writing because of course the network device itself can take that configuration and turn it into actionable information. However, that does us no good, as most vendors aren’t open sourcing their internal operating systems’ parsing logic.

Status vs. Configuration

In the two examples above, we received output from a network device after we issued a command via the CLI. One gave us some sort of status about the device, and the other gave us information about its configuration. Broadly speaking, all CLI commands on a network device fall into these two categories. You are either gathering or changing the status of the device with commands such as show version, show flash, or clear counters. Or you are gathering or changing the configuration of the device with commands such as show running-config, or config t;interface e1/0;no shutdown.

It is vital to keep in mind which type of information you’re looking for or what changes you are trying to make, and whether it involves the device’s status or configuration. This will heavily influence how you parse/interact with the output that the device has given you. Some parsing methods or libraries are made specifically for turning configuration into something easy to manipulate/change in Python (CiscoConfParse, Heir Config), and some are more generic and can parse both status and configuration (Regex, TextFSM, Genie).

In the next post, I’ll dive into CiscoConfParse first, and we’ll see how it can make the act of understanding and manipulating traditional unstructured network device configuration much simpler.

Parsing Network Device Output Part 1: Regex

brett@network-notes.com (Brett Lykins) — Wed, 04 Mar 2020 20:17:00 -0500

In the Beginning

Often when making their first steps into Network Automation, people may have an idea of what they want to do, but not exactly how to get there. For example, an engineer may want to simplify a single time-intensive task “Gather the SW version, serial numbers, and uptime from all of my Cisco ASAs.” However, upon getting the information, they’re unsure what to do with it or how to parse it and use it for something else. I’ve seen this question come up a few different times, and thought a series of blog posts was in order. Each of the posts (including this one) outline some sample parsing options. However, it is worth noting that Regex is not better or worse than using a parsing library, for example, they may just have different use cases.

First, in this post, I will outline the basics of gathering our information and parsing it directly with our own Regular Expressions (Regex).
Next, I will demonstrate parsing this information with the popular CiscoConfParse and HeirConfig libraries.
Third, I will demonstrate simple parsing with Google’s TextFSM and the awesome library of templates provided by Network To Code, ntc-templates.
Finally, I will demonstrate simple parsing with Cisco’s Genie/PyATS libraries.

Note that I am going to skip over a lot of the minutia of what Netmiko is, and how to use it to gather network device information, as there are many wonderful resources out there already on this. We’re going to focus primarily on what to do with the output once you have it.

In this series of posts, we’ll just use the simple network shown here. There is a Management Station with Python 3.8 installed, and two Cisco ASAv firewalls (ASAv1 and ASAv2) in a tiered setup.

Code samples and “requirements.txt” for this post can be found on my Github.

Environment Preparation

For this entire series of posts, I will be working the examples in a python virtual environment setup with the following dependencies installed. Note that we’re installing iPython, which is a much better alternative to the built in Python interactive shell. I highly recommend checking it out by executing ipython in this virtual environment. iPython allows us to do some more interactive introspection on objects and method/object doc_strings in real time, which we’ll use in later posts.

iPython
Netmiko
CiscoConfParse
HeirConfig
NTC Templates
Genie/PyATS

First, I create a virtual environment with whatever name you wish, and then activate that environment:

1
2


python3.8 -m venv nn_examples
cd nn_examples;source bin/activate

Next, I install the dependencies as discussed above:

1

pip install ciscoconfparse genie hier-config ipython netmiko ntc_templates pyats

Gathering our Output

We need to instantiate a connection to our ASAs, and then execute the command “show version | inc So|Serial| up” against them to gather the needed output. Simple enough with Netmiko as shown below (or on Github):

raw_gather.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


# !/usr/bin/env python3

"""
Example code for Network-Notes.com entry on Parsing Network Device Output
"""

import getpass
import re
import sys

from netmiko import ConnectHandler

"""
Test parsing network device configuration
"""

# Gather the needed credentials

net_device_username = input("Username: ")
net_device_password = getpass.getpass()

# Set enable/secret = password for now

net_device_secret = net_device_password

# Setup a dict with our ASAvs in it, in real world this could be read

# from a CSV or the CLI or any other source

firewalls = {
 "ASAv1": {"ip": "10.10.10.50", "platform": "cisco_asa"},
 "ASAv2": {"ip": "10.10.60.2", "platform": "cisco_asa"},
}

# Setup an empty dict for our results

results = {}

# Instantiate netmiko connection objects and gather the output of

# `show version | inc So|Serial| up` on these two firewalls

for fw_name, fw_data in firewalls.items():
 print(f"Connecting to {fw_name}...")
 fw_connection = ConnectHandler(
 ip=fw_data["ip"],
 device_type=fw_data["platform"],
 username=net_device_username,
 password=net_device_password,
 secret=net_device_secret,
 )
 results[fw_name] = fw_connection.send_command(
 command_string="show version | inc So|Serial| up"
 )

# Print our results

for fw_name, result in results.items():
 print(f"{fw_name} information:\n")
 print(result)

sys.exit()

Successfully executed with “python3.8 raw_gather.py”, this will output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 Username: cisco
 Password:
 Connecting to ASAv1â€¦
 Connecting to ASAv2â€¦
 ASAv1 information:

 Cisco Adaptive Security Appliance Software Version 9.12(1)2
 ASAv1 up 23 mins 50 secs
 Serial Number: 123456789AB

 ASAv2 information:

 Cisco Adaptive Security Appliance Software Version 9.13(1)2
 ASAv2 up 24 mins 5 secs
 Serial Number: 123456789AC

Now that we have an example of gathering the information, let’s parse it to python variables via Regex.

Parsing with Regex

Much like above, I will not exhaustively cover what Regex (Regular Expressions) are, as there are boundless resources on the internet (and good old O’Reilly books) that do this. Suffice to say for our purposes, that it is a way to match patterns in a string of text and gather output based on that, and that I strongly recommend finding a good test bed like Regex101 to help you along the way. You can get extremely complicated with Regex, and it can also bite you in the behind, just ask Cloudflare… Here is the three Regular Expressions I am using to match relevant output from the ASA with links to Regex101 examples demonstrating them.

Software Version:
- Software Version (\d.\d{1,2}(?:(?\d{1,2}?)?\d{1,2}?)?)\W*$
Uptime:
- up (.*)$
Serial Number:
- Serial Number: (\S*)$

Now here is what the program looks like utilizing the python re Regex module. The only difference is the addition of a section for parsing the output we’ve received, so that is all I’ll list below. The complete file is on Github as parse_with_regex.py:

raw_gather.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# Parse our results

print("Parsing Results...")
parsed_results = {}
for fw_name, result in results.items():
 parsed_results[fw_name] = {}
 parsed_results[fw_name]["version"] = re.search(
 r"Software Version (\d.\d{1,2}(?:\(?\d{1,2}?\)?\d{1,2}?)?)\W*$",
 result,
 re.MULTILINE,
 )
 parsed_results[fw_name]["uptime"] = re.search(
 r"up (.*)$", result, re.MULTILINE
 )
 parsed_results[fw_name]["serial"] = re.search(
 r"Serial Number: (\S*)$", result, re.MULTILINE
 )

# Print our results

for fw_name in results.keys():
 print(f"{fw_name} information:\n")
 print(f"\tVersion: {parsed_results[fw_name]['version'].group(1)}")
 print(f"\tUptime: {parsed_results[fw_name]['uptime'].group(1)}")
 print(f"\tSerial Number: {parsed_results[fw_name]['serial'].group(1)}")

This will give us the results of:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Username: cisco
 Password:
 Connecting to ASAv1â€¦
 Connecting to ASAv2â€¦
 Parsing Resultsâ€¦
 ASAv1 information:
 Version: 9.12(1)2
 Uptime: 1 hour 25 mins
 Serial Number: 123456789AB
 ASAv2 information:
 Version: 9.13(1)2
 Uptime: 1 hour 25 mins
 Serial Number: 123456789AC

As you can see, this is a much more structured and useful output. We could also similarly output this to a CSV or other data source, now that we have parsed the data into something of more value than a raw string of all the data.

Next Up, Parsing Libraries

In the next post I publish, I will utilize this same environment, but make use of some common configuration parsing libraries (CiscoConfParse and HeirConfig) to show how they could be useful for certain use cases.

Cisco Certification Program Refresh

brett@network-notes.com (Brett Lykins) — Mon, 10 Jun 2019 12:30:00 -0500

One of the primary reasons I originally started this blog, was to use it for personal accountability with my Cisco certification progress. As I studied and understood a particular topic, I could write a blog article on that topic to cement it in my mind and share that knowledge with others.

The complete lack of blog posts reflects how well that plan went… I did complete my CCNP Security and was in pursuit of my CCIE Security when my career trajectory shifted. No longer was I solely a Network or Security Architect, an increasing portion of my role was focused on Network Automation and solving problems at a massive scale. I stopped chasing traditional networking certifications and spent many thousands of hours learning Python and Golang to best solve the problems I was faced with at my job.

While that work has been fulfilling and challenging, it doesn’t present itself well to the traditional Networking world mindset of “certification chasing”. Since I stopped actively pursuing Cisco certifications I have had more than one conversation where people have asked things like: “So where’s your CCIE at?” or “Are you going into management now?” As I looked at the Cisco certifications available, there wasn’t one that presented value to me and the work I was doing every day, beyond the basic knowledge acquired in getting my CCNA and CCNP Voice, Security, and Route/Switch in the past. I couldn’t justify the expense (in both money and time away from my family) to chase a CCIE if it didn’t apply to my career.

Well as of today, Cisco is announcing something that changes all of that, and I’m super excited. They are doing a complete, top to bottom, refresh and realignment of the certifications that are offered, and the process to get/keep them.

New and Improved Cisco Certifications

All the discussed changes below go into effect on February 24th, 2020. So you’ve got time to finish your existing studies or gear up for a new certification/track.

First and foremost, and the most personally exciting to me, is that there is a completely new certification track:

The New Certification Tracks from Cisco!

Now Network Automation/Netdevops is to be recognized via DevNet certifications in their track! Including up to a forthcoming DevNet Expert certification targeted at the same level of expertise expected out of CCIE-level folks.

According to DevNet the DevNet Professional level exam/certification is targeted at:

… developers who have at least three to five years of experience designing and implementing applications built on Cisco platforms. Two exams cover designing and developing resilient, robust and secure applications using Cisco APIs and platforms, and managing and deploying applications on Cisco infrastructure.

Cisco DevNet

This is exactly where I find myself sitting today, and I’m super excited to see that Cisco and the folks at DevNet are listening to the community and responding to this need! I will be one of the first people in line next February when these exams go live. And I can 100% see the value in pursuing the DevNet Expert examination in my career path.

Additional Changes

There are some significant changes to the certification paths, even inside the existing network-focused paths.

No more prerequisites for any Cisco certification, if you’re at the Professional or Expert level in your field, go sit that exam.
All certifications are good for 3 years from the last pass date (including Expert level).
There are now additional options, including Continuing Education, for renewing your certifications at all levels.
Associate level (CCNA or DevNet Associate) is one exam.
Professional level (CCNP or DevNet Professional) is two exams:
- A Core skills exam in your track.
- A Concentration exam in a more specific area of focus to your specialization.
Taking additional specialization exams will grant you Cisco Specialist badges/awards.
The tracks available to the Networking path narrow down to Enterprise, Security, Service Provider, Collaboration, and Data Center.
- For example, Route/Switch and Wireless are being collapsed into the Enterprise track.
- Each of these topics now exists as a concentration or specialization exam inside the Enterprise track at the Professional level.
- If you’re mid-CCNP and want to know what the path forward for you looks like:

As noted, these changes will go into place on February 24th, 2020. However, exam topics and other information are now live via the links below. And expect MANY blog posts and other information from Cisco in the coming days, weeks, and months.

Happy Certing!

#CiscoChampion 2019

brett@network-notes.com (Brett Lykins) — Fri, 04 Jan 2019 08:18:00 -0500

Happy 2019 everyone! Since I was lucky enough to be selected as a Cisco Champion for 2019, I thought it was time to revive my zombie blog!

I’ve got quite a few posts in the hopper and will focus on not being such a perfectionist to posts that I don’t just hit that “Publish” button. Posts will be coming about:

Network Security
Network Programmability
Python
Systems Architecture
And more!

Here’s to an exciting and educational 2019!

Testing ISAKMP Part 1: Basic Connectivity

brett@network-notes.com (Brett Lykins) — Fri, 20 May 2016 22:44:00 -0500

The Scenario

In the course of my day-to-day job, I interact with VPNs on many devices (primarily IPSec VPNs on the Cisco ASA). Oftentimes the simplest way to test an IPSec VPN is to fire up vpnc in a VM, change the config file as needed, and validate the connection.

Sometimes though, you need to be more granular with your testing. Perhaps the person controlling the other endpoint/peer is not in charge of the intermediate network, and you need to validate that ISAKMP traffic is allowed through to the peer. Perhaps you want to validate an ACL that should be blocking ISAKMP. Or perhaps you’re just curious to gain a deeper understanding of what is happening at the protocol level. Either way, there’s no easy way to validate that ISAKMP is permitted end to end.

Because ISAKMP utilizes UDP port 500 for transport, you can’t simply Telnet to the port and validate that it is permitted. We’re talking about UDP, not TCP, which means there is no Layer 4 validation of an open socket (the Three-Way-Handshake of TCP). This means that you can’t do something like nc -uvv $host 500 because while netcat can certainly open and utilize UDP sockets, netcat alone can’t tell you if a UDP port is open and listening. To test this below, I attempt to use netcat to check whether my local box is listening on UDP port 500 (which I know it is not):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


$ nc -uvv 127.0.0.1 500
 found 0 associations
 found 1 connections:
 1: flags=82
 outif (null)
 src 127.0.0.1 port 59894
 dst 127.0.0.1 port 500
 rank info not available

Connection to 127.0.0.1 port 500 [udp/isakmp] succeeded!

Succeeded indeed… Although we need to do something more to validate whether UDP/500 is open and listening for ISAKMP datagrams, as mentioned above we can still actually utilize netcat We can use it to open the UDP socket and then pipe in semi-valid ISAKMP data for netcat to pass to our destination. This way, we can at least get some sort of response or validation via either an ISAKMP reply message or debugs/counters on the far side peer.

RFC2048 – Internet Security Association and Key Management Protocol

ISAKMP is defined in RFC2048, which describes in great detail the underlying structure of an ISAKMP UDP datagram. In section 3.1, it lays out the header format which is all we need for testing:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Initiator !
 ! Cookie !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Responder !
 ! Cookie !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Message ID !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Length !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Essentially, if you haven’t seen this style of packet diagram, each number across the top represents a bit, and each row represents 32 bits or 4 octets/bytes whichever you prefer. In this case, the ISAKMP header is 7 rows tall, which means that the ISAKMP header is 224 bits (7*32), or more commonly, 28 bytes long.

Now we know how long the data has to be, but what are we going to put into it? The header breaks down into the following chunks:

Initiator and Responder Cookies
- 8 bytes per Cookie
- These are tokens that enable each endpoint to identify Security Associations (RFC2048, Sec 2.4), and to act as a method to assist in securing the communication (RFC2048, Sec 2.5.3).
- Also known as the Security Parameter Index (SPI).
Next Payload
- 1 byte
- Indicates what type of message is following this header.
Major Version and Minor Version
- 4 bits each
- Set to 1 and 0 respectively in RFC2048.
Exchange Type
- 1 byte
- Tells the other system what type of messages and payloads to expect.
Flags
- 1 byte
- Set specific ISAKMP options; only the first three bits are specified in RFC2048 rest are to be zeros.
Message ID
- 4 bytes
- A unique ID is used in Phase 2 negotiations; as we’re simulating a Phase 1 datagram these are set to all zeros.
Length
- 4 bytes
- The combined length of the header and payloads is represented in bytes/octets.

Taking this information, we are now able to determine what fields we need to fill out and with what values to create our testing datagram. Once we are complete, we can simply feed the appropriate arrangement of binary into netcat, and it should be able to simulate the beginning of a valid ISAKMP exchange with the peer.

The only hitch with this plan is the need for binary. For mere humans, visually tracking long strings of binary is not easy; at a glance can you tell if this is 7 or 8 digits 00000001? In addition, writing out each byte would get tedious and increase the likelihood of human error.

Hexadecimal to the Rescue

Luckily we can shortcut this process by representing the binary values with Hexadecimal in \x notation. This allows us to simply represent each byte or octet as a four-character string. For example:

1
2
3
4
5


Binary: 000000000000000100000010000000011
Hexadecimal: \x00\x01\x02\x03

Validation using xxd:
printf '\x01\x02\x03\x04' | xxd -b 0000000: 00000001 00000010 00000011 00000100 ....

Working with that format, and referencing the above breakdown of the header format gives us the following Hexadecimal:

Initiator and Responder Cookies
- 8 bytes per Cookie
- Initiator Cookie
  - We’ll make this a value of 1 since it has to be something and we don’t care what it is.
  - \x00\x00\x00\x00\x00\x00\x00\x01
- Responder Cookie
  - All zeros because this is an initial communication.
  - \x00\x00\x00\x00\x00\x00\x00\x00
Next Payload
- 1 byte
- No Next Payload, so a value of 0.
- \x00
Major Version and Minor Version
- 4 bits each
- Mandatory values of 1 and 0, because we’re using ISAKMP version 1.0
- That would be 0001 and 0000 in binary.
- Together, that would look like 00010000, which equals 10 in Hex.
- \x10
Exchange Type
- 1 byte
- We’re making a fake datagram with no payload, so we’ll try none (0) which appears to be permitted by RFC2048.
- \x00
Flags
- 1 byte
- No specific flags are needed, so we’re also setting this to 0.
- \x00
Message ID
- 4 bytes
- Must be zeros per RFC2048 for an initial Phase 1 datagram like we’re simulating.
- \x00\x00\x00\x00
Length
- 4 bytes
- This will be equal to 28 since we have a header with no payload.
- 28 in Hex is 1C.
- \x1C

Finally, our complete string of Hex for the simulated initial ISAKMP datagram would be:

1

\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x1C

Sending Our Data

Now that we have the complete Hex string for our test datagram, how do we go about sending it? Well as described earlier, we’re going to simply pass it into netcat by printing the string and piping it into netcat. But first, we need to get a destination setup that is listening for ISAKMP traffic. In my case, I’ve spun up a virtual Cisco ASA in my lab to act as our peer, and have it listening for ISAKMP traffic on the INSIDE interface (172.16.16.1).

1
2
3
4
5
6
7
8
9


ASAv-1A/pri/act# show run int G0/4
!
 interface GigabitEthernet0/4
 nameif INSIDE
 security-level 100
 ip address 172.16.16.1 255.255.255.0
 standby 172.16.16.2
ASAv-1A/pri/act# show run crypto ikev1
 crypto ikev1 enable INSIDE

Taking the above Hex string and using printf to send it into netcat gives us the following output (all of the Hex should be on one line, however for readability I have broken it up here):

1
2
3
4


$ printf \x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00
 \x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x1C | nc -uvv 172.16.16.1 500
Connection to 172.16.16.1 500 port [udp/isakmp] succeeded!
^C

As you can see, netcat says “Connection succeeded” again, and the output on our end is not so different from when we tested to a non-ISAKMP speaking endpoint. However, on the ASA IKEv1 statistics, we can see something very interesting:

1
2


ASAv-1A/pri/act# show crypto ikev1 stats | inc Drop
In Drop Packets: 6 Out Drop Packets: 0

So the ASA saw the packet and marked it as invalid in some way then dropped it (which makes sense because we didn’t send any payload at all).

This validates that the path for UDP/500 is open from my test box to the peer!

Bonus Validations

I’m a curious soul though, so I wanted to dig deeper still. For more detail we can turn on the IKEv1 debugs on the ASA and see as it is receiving and discarding each of the packets:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


ASAv-1A/pri/act# debug crypto ikev1 255
ASAv-1A/pri/act#
May 21 03:25:04 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:04 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:04 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:04 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:05 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:05 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:06 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:06 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:07 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:07 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:07 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:07 [IKEv1]IKE Receiver: Discarding packet, invalid IKE version

And for the coup, I did a packet capture on the ASA for all UDP/500 traffic and decoded it to see if the protocol decoder could interpret the frames as ISAKMP:

1
2
3
4
5
6
7
8


ASAv-1A/pri/act# cap cap1 int INSIDE match udp any any eq 500
ASAv-1A/pri/act# show cap cap1 decode 6 packets captured
 1: 03:34:01.443916 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 2: 03:34:01.444007 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 3: 03:34:02.444892 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 4: 03:34:03.445609 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 5: 03:34:04.447059 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 6: 03:34:04.450126 172.16.16.16.35457 > 172.16.16.1.500: udp 75 ISAKMP Header Initiator COOKIE: 78 30 30 78 30 30 78 30 Responder COOKIE: 30 78 30 30 78 30 30 78 Next Payload: IKEV2 LEAP PAYLOAD Version: 3.0 Exchange Type: DOI Specific Use Flags: MessageID: 30783031 Length: 2016424056 [ISAKMP payload corrupted or truncated]

And there you have it, a means to quickly and easily validate a UDP/500 path!

Series Update (2026)

This post has been expanded into a comprehensive series:

Part 1 (this post): Basic connectivity testing with minimal ISAKMP headers
Part 2: Testing with pre-built complete packets
Part 3: Building ISAKMP packets from scratch
Part 4: Automating tests with Scapy (coming soon)

300-208 SISAS - What Is Cisco ISE?

brett@network-notes.com (Brett Lykins) — Sat, 12 Dec 2015 21:20:00 -0500

In my earlier post about the Cisco 300-208 SISAS (Implementing Cisco Secure Access Solutions) exam, I gave a brief overview of the exam and listed the exam topics as laid out by the Cisco Learning Community. However, I felt that these largely boil down to a few key concepts related to Cisco ISE (Identity Services Engine):

Understand what ISE is.
Understand why you might use ISE in a wired or wireless network.
Understand what ISE does at a protocol level.
Understand how ISE interacts with Network Access Devices and other systems.
Understand how to configure ISE and the Network Access Devices.

This post will deal with Concept 1, Understand what Cisco ISE is.

A Little History

Before you can understand what ISE is, I feel that you need to know where it came from. Cisco’s NAC (Network Access Control) offerings have been fairly scattershot over the years. They even tried unsuccessfully to market a contrary meaning of NAC for several years, attempting to sell their services as Network Admission Control. Thankfully, they’ve given in and joined the rest of us in Network Access Control land.

Cisco ACS (Access Control Server) was the direct predecessor to ISE and still exists today. It provides RADIUS and TACACS services and can integrate with central Identity Stores such as Active Directory or another LDAP-speaking software. This means that you would often find ACS in an enterprise network serving to authenticate VPN and wireless users or control access to network devices. Over time ACS evolved, as most Cisco applications have, from something you installed on top of Windows, to a full-blown Linux-based appliance (as of ACS 5.0 in 2009). The common “appliance” model in use today, means that without a little (non-Cisco approved) tinkering you don’t have access to the Linux guts of Cisco ACS, or ISE for that matter, you’ve simply presented an application.

At the same time that ACS was growing and advancing in capabilities, there was also the burst of BYOD onto the market and a growing market in servers/services to manage and administer user Identity on the network. Cisco saw an opportunity to forklift the capabilities of ACS into a new product that was targeted directly at the “new” Identity Management market, not just traditional “access control”. They took the underlying operating system from ACS, a RHEL/CentOS-based distribution that they call ADE-OS (Application Deployment Engine), and added a few new capabilities and features to the application. This creation is what we know today as Cisco ISE. Essentially, you can think of ISE as ACS version 6.0.

The only thing left out of ISE (until the recent release of Cisco ISE v2.0) was TACACS, as it was intended that you still purchase ACS to control network device administrative access. For the 300-208 SISAS exam today, you can consider TACACS to be out-of-scope for ISE, and to be the sole purview of ACS, although you still have to understand TACACS for the exam.

What Is Identity Management?

A full discussion of what Identity and Identity Management is, could take up many pages and posts (see Wikipedia), however for the 300-208 SISAS exam it can be summed up as this from the Official Cert Guide:

An identity is a representation of who a user or device is. Cisco ISE uses an endpoint’s MAC address to uniquely identify that endpoint. A username is one method of uniquely identifying an end user. Although SSIDs and IP addresses can be used as conditions or attributes in ISE policies, they are not identities.

Woland, Aaron; Redmon, Kevin (2015-04-27). CCNP Security SISAS 300-208 Official Cert Guide (Certification Guide) (Kindle Locations 13023-13026). Cisco Press. Kindle Edition.

An Identity Management system can then be defined as a way to keep track of Identity information for many users or devices, as well as the associated Authorization and Authentication information for those entities. This is precisely what Cisco ISE is and does. It provides all manner of services related to managing who users and devices are, and what network resources they may access. Cisco ISE does not directly stop an entity from accessing a portion of the network (there are sometimes Inline Policy Nodes, but they are not common). The Network Access Devices themselves handle the heavy lifting of granting/denying access by utilizing IEEE 802.1x which I will discuss in a subsequent post. ISE simply provides a centralized location to set policy, gather reporting, and then interact with the NAD via Radius.

In the next post, I will delve into Concept 2, the Whys surrounding Cisco ISE, as well as give a few example use cases.

The Elusive A+ Rating on SSL Labs

brett@network-notes.com (Brett Lykins) — Mon, 24 Aug 2015 22:58:00 -0500

I often have to talk people off a cliff because of their website’s (sometimes perceived) vulnerabilities on Qualys’ SSL Labs testing site. They have received an A- score for their site after running the tests, and see a few things in yellow. Suddenly, they begin to believe that every villain on the web is now running amok with their data. The truth of the matter is that if your SSL configuration is rating at an A-, that configuration is usually just fine. Out of curiosity, I recently spent a few hours tweaking and managed to upgrade from an A- to an A+ for this domain. I wanted to share that process so that anyone else can know what it might take to get an A+.

A+ Rating for network-notes.com on Qualys SSL Labs Testing

Caveats and Advice

The things that get you to an A+, are mostly semantic and not always the most obvious and open vulnerabilities. The SSL Labs scoring process, while open and based on common sense/best practices, is simply one entity’s opinion of your SSL configuration. In addition to the somewhat arbitrary nature of any benchmarking site, such as SSL Labs, remember that a configuration that gets an A+ today is one new vulnerability away from an F. Your security posture on any system must be continuously evolving, along with the threats you’re defending against.

These caveats also hold for any configurations listed here. These are not guarantees that your site will be secure, or even recommendations. They merely reflect the Apache and mod_ssl configurations that suited my needs, in my circumstances, at the time of this writing. Please use common sense when establishing an SSL policy for your website.

The tweaks boiled down to either explicitly defining things in my Apache VirtualHost configuration that I assumed didn’t matter, or bending my strict configuration a little bit to meet the requirements of older browsers. For example, I was initially only going to enable TLSv1.2. If you can’t support TLSv1.2, I wasn’t really worried if the site was unavailable to you. However, as I thought about it, I realized that it was a pointless stance to take. Why isolate this site from an unfortunately large, albeit less secure, portion of the web when I don’t have to? I’m not hosting any sensitive information on these servers; I am not asking users to make credit card transactions or give me their Social Security numbers. I eventually walked my SSL configuration backward and enabled TLSv1.0, TLSv1.1, and TLSv1.2 as part of my remediation efforts to get the elusive A+ from SSL Labs.

How to Get an A- Without Really Trying

Below is an example of the Apache VirtualHost configuration I had in place before beginning this process. It was graded at an A- by SSL Labs and is pretty standard. Most of it was pulled directly from the default-ssl.conf file in Apache 2.4.

Starter Apache Config

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


<IfModule mod_ssl.c>
 <VirtualHost *:443>
 ServerName network-notes.com

 # SSL Configuration
 SSLEngine on
 SSLProtocol +TLSv1.1 +TLSv1.2
 SSLCipherSuite HIGH:!aNULL:!MD5
 SSLCertificateFile network-notes.com.pem
 SSLCertificateKeyFile network-notes.com.key
 SSLCertificateChainFile network-notes.com-cabundle

 # Fixes for IE being, well, IE...
 BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown
 \downgrade-1.0 force-response-1.0
 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

 # Browser caching for static content
 <filesMatch ".(js|css|png|jpeg|jpg|gif|ico|swf|flv|pdf|zip)$">
 Header set Cache-Control "max-age=1209600, public"
 </filesMatch>

 # Redirect "/" to "/blog/"
 <If "%{REQUEST_URI} == '/'">
 Redirect "/" "/blog/"
 </If>

 </VirtualHost>
</IfModule>

Now, here’s what the good folks at Qualys SSL Labs had to say about that configuration:

“The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-. MORE INFO»”
1. “Forward Secrecy - With some browsers (more info)”
“Incorrect SNI Alerts - <www.network-notes.com>”
In addition, unless a browser was one of the newest versions available, there was also a slew of “Protocol or cipher suite mismatch”.

Working Towards an A

The easiest fix was enabling TLSv1.o as I described earlier. By simply adding +TLSv1 to the SSLProtocol directive, I opened up a much larger range of possible Protocol/Cipher Suite combinations:

1

 SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2

Unfortunately, this change resulted in no movement whatsoever of my A- rating. At the very least, issue #3 was resolved; the wide majority of browsers could negotiate a connection. The question remains, however, why would Forward Secrecy only work with some browsers? I have configured all of the DHE and ECDHE ciphers needed and was able to confirm this fact because many browser simulations can connect with an ECDHE cipher. Upon further investigation of the output from SSL Labs, I found the following, “Cipher Suites (sorted by strength as the server has no preference)”. The Forward Secrecy enabled ciphers are available to all browsers, but I wondered if SSL Labs was indicating that some might not pick them because they weren’t offered first.

I always assumed cipher suite order was generally arbitrary, but to appease SSL Labs I sorted them by strength. I added @strength to the end of my SSLCipherSuite directive, and also added the SSLHonorCipherOrder directive. The SSLHonorCipherOrder directive was because, if I’m going to sort my cipher suite, your browser better obey.

1
2


 SSLCipherSuite HIGH:!aNULL:!MD5:@STRENGTH
 SSLHonorCipherOrder on

Upon testing again I had… Success! I was upgraded to an A!

From SSL Labs: “Forward Secrecy - Yes (with most browsers) ROBUST (more info)” There is now only one more issue in yellow, so I assumed that fixing the SNI mixup should get me to an A+.

SNI-ed Remarks

The SNI error given was not exactly verbose: “Incorrect SNI Alerts - <www.network-notes.com>”. This was a little puzzling, as I’m not using SNI for this site; there’s only one domain hosted on the server. After Googling for a few minutes, I found myself at a Qualys Community post from August 2014 detailing this issue. Most helpful it gave a quick and dirty test to validate the issue yourself using OpenSSL (openssl), which I tweaked as shown below to look for unrecognized name SSL alerts. You can see in the first example using network-notes.com, that there was no issue. However, when using <www.network-notes.com>, the server was indeed giving back an unrecognized name error:

1
2
3
4
5
6


$ SERVER=network-notes.com; echo -e "HEAD / HTTP/1.0\r\nHost: $SERVER\r\n\r\n" | openssl s_client -servername $SERVER -connect $SERVER:443 -state 2>&1 | grep unrecognized
$

$ SERVER=www.network-notes.com; echo -e "HEAD / HTTP/1.0\r\nHost: $SERVER\r\n\r\n" | openssl s_client -servername $SERVER -connect $SERVER:443 -state 2>&1 | grep unrecognized
SSL3 alert read:warning:unrecognized name
$

This is a perfect example of the minutia you have to wade through in search of an A+. My DNS for this domain is configured with <www.network-notes.com> as a CNAME for network-notes.com, so no one should ever wind up at <www.network-notes.com>. However, since it is a SAN in my SSL certificate, according to Qualys I need to specify it as a ServerAlias in my Apache VirtualHost configuration:

1

 ServerAlias www.network-notes.com

This change cleared up the SNI error on SSL Labs, and in my testing, however, my grade is still (only?) an A. Now it’s time to think this through and re-read the output from SSL Labs.

Headed for an A+

One of the lines indicated that I did not have the HSTS (HTTP Strict Transport Security) enabled. There’s a great summary of HSTS, including sample configurations at Raymii.org, but essentially it is an HTTP header that is returned to your browser on the first visit. This header tells your browser to always use HTTPS for any subsequent visits to your domain. Since I have all traffic redirecting to HTTPS already, I figured this would be a simple addition. After all, at this point, I was grasping at straws and I added the following configuration:

1

 Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

And finally, lo and behold, the elusive A+!

Quote from the test: “This server supports HTTP Strict Transport Security with long duration. Grade set to A+.”

Final Results

Now that we have the A+, I figured I should go ahead and complete the other task that I was considering as a possibility, configuring OSCP Stapling. This was a simple enough configuration consisting of two additional lines, one defining where the OSCP Stapling cache would be and another turning the feature on. While this change didn’t upgrade my SSL Labs score any further (A++ anyone?), it did green up another field. After all this time working on the configuration was still fairly satisfying.

Below is an example of what my SSL VirtualHosts file looked like after all of these contortions. I hope you all find it useful, and please let me know if you all have any recommendations, corrections, or your own stories of optimizing SSL.

Final Apache Config

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


<IfModule mod_ssl.c>
 SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
 <VirtualHost *:443>

 ServerName network-notes.com
 ServerAlias www.network-notes.com

 # SSL Configuration
 SSLEngine on
 SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
 SSLCipherSuite HIGH:!aNULL:!MD5:@STRENGTH
 SSLHonorCipherOrder on
 SSLCertificateFile network-notes.com.pem
 SSLCertificateKeyFile network-notes.com.key
 SSLCertificateChainFile network-notes.com-cabundle
 SSLUseStapling on

 # HSTS Configuration
 Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

 # Fixes for IE being, well, IE...
 BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown
 \downgrade-1.0 force-response-1.0
 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

 # Browser caching for static content
 <filesMatch ".(js|css|png|jpeg|jpg|gif|ico|swf|flv|pdf|zip)$">
 Header set Cache-Control "max-age=1209600, public"
 </filesMatch>

 # Redirect "/" to "/blog/"
 <If "%{REQUEST_URI} == '/'">
 Redirect "/" "/blog/"
 </If>

 </VirtualHost>
</IfModule>

300-208 SISAS - How to Tackle the Beast

brett@network-notes.com (Brett Lykins) — Wed, 19 Aug 2015 23:09:00 -0500

The best way to finish something is to begin it. So I decided I would begin my prep for the 300-208 SISAS (Implementing Cisco Secure Access Solutions) exam, by laying out my personal study plan against the exam topics, found here on the Cisco Learning Community.

The exam topics are broken into five broad categories, and Cisco also gives a general indication of what percentage of the exam is on each topic:

1.0 Identity Management/Secure Access - 33%
2.0 Threat Defense - 10%
3.0 Troubleshooting, Monitoring, and Reporting Tools - 7%
4.0 Threat Defense Architectures - 17%
5.0 Identity Management Architectures - 33%

Each of those broad topics has several sub-categories; 1.0 Identity Management/Secure Access, for example, is broken down into over 60 sub-sections. This depth of expected knowledge can seem quite daunting at first, especially given the vague nature of some of the topics. However, I’ve found that the exam breaks down into 5 key areas, and are all focused primarily on Cisco ISE (Identity Services Engine):

Understand what ISE is.
Understand why you might use ISE in a wired or wireless network.
Understand what ISE does at a protocol level.
Understand how ISE interacts with Network Access Devices and other systems.
Understand how to configure ISE and the Network Access Devices.

This is why my primary focus in these exam preparations is getting hands-on with Cisco ISE. I have been spending at least 10 minutes per night, getting familiar with both the GUI itself and the operations that ISE can do. 10 minutes may not seem like much, but getting any hands-on time with a complex system matters. You have to keep yourself sharp and fresh when preparing for an exam. Especially if, like in my current job, you do not interact with ISE at all on a day-to-day basis.

In the next few posts, I’ll dig further into each of these 5 key areas, as well as discuss how to set up an ISE test lab for yourself and talk through some of the scenarios I’m using for my lab.

CCNP Security - Halfway There

brett@network-notes.com (Brett Lykins) — Sat, 15 Aug 2015 21:52:00 -0500

I am halfway towards my CCNP Security and am finally gearing up to finish it. When I completed the 642-618 FIREWALL and 642-648 VPN exams at the beginning of 2014, I was promptly sidetracked by the little things in life. (Such as moving across the country, starting a new job, and finishing my BSIT at WGU.) Knowing that the old CCNP Security exams had cycled out in April of 2014, I used Cisco’s CCNP Security Migration Path tool to validate that I was left with these two exams:

300-207 SITCS (Implementing Cisco Threat Control Solutions)
300-208 SISAS (Implementing Cisco Secure Access Solutions)

I am starting first with the 300-208 SISAS exam as it covers a range of topics, such as 802.1x, Cisco ISE, and Radius, that I am very familiar with. However, from everything I’ve read, it goes into great depth on the minutia of the ISE interface. As I haven’t touched ISE in a production environment in over a year now, I’ve been spending time most evenings in my lab spinning up and down many different scenarios.

My lab for this study is entirely virtual and is a dry run for building my CCIE Security lab. It currently consists of the following, largely coordinated and controlled via GNS3:

ISE 1.2 - VMWare Fusion on my MacBook
ACS 5.6 - VMWare Fusion on my MacBook
CentOS test boxes (x2) - VMWare Fusion on my MacBook
IOU L2 Image (x2) - Rackspace Cloud Server
IOU L3 Image (x6) - Rackspace Cloud Server
ASA 8.4 (x2) - QEMU on a Rackspace Cloud Server

In the weeks to come I’ll be posting more about my exam preparations, including lab scenarios and links. This is mostly for me, but if anyone else gets some use out of it too, even better.