Project rockhammer

Design Goals

• consistant platform, consistant behavior
• unified configuration to ease provisioning and maintenance, promote familiarity.
• reliability: at least to the level provided by the underlying OS. preferrably more.
• easily documented

Software Architecture

• (early) pf for filtering, NAT, filter-forwarding, etc.
• (late) carp for redundancy (failover/load balancing)?
• same platform for any hardware combination

Hardware Architecture

• (early) simple single-machine model for proof-of-concept, lower-end device
• (late) multiple machines in a single chassis, split control/forwarding plane

Configuration

• (phase 1) single config file
• (phase 2) config shell
• (!) candidate vs committed configuration
• currently, a reboot will sync on-disk config to in-core, but no mechanism exists to do the opposite (in core -> on disk): this is the real problem to solve, and the biggest win.

C-F plane link

• Underlying UDP transport from dedicated NIC on each plane
• Should work fine for single-machine setup, maybe use unix socket in this case for performance?
• Probably best written in C eventually: a prototype in a higher level language is a prudent step
• Custom protocol, custom code: optimized flow for operations.
• Caching routing table on forwarding plane? Has some interesting benefits and drawbacks, and warrants its own section here.. (TODO)

Design Problems

• Source packets from control plane, but really source them from forwarding plane: NAT tricks, or ssh-rcmd?
• pf config in single config file: parse it, embed it inline, ?
• heavy use of regression testing would be beneficial.
• how does one update the system?

Lessons Learned Elsewhere

• "commit confirmed": best to avoid hosing oneself.
• allow access to inspect all components, but don't make it a requirement
• having a real onboard editor, and valid [configurable] line editing makes people happy.
• read-only root filesystem and ramdisks makes for a survivable system
• give the people what they want: OpenVPN, SSH

Misc Notes

• All custom code/patches should be considered for submission to upstream repositories: written with this in mind. Use generic mechanisms that could be useful to others.