Difference between revisions of "Project rockhammer"

From WTFwiki
Jump to navigation Jump to search
m (6 revisions)
(No difference)

Latest revision as of 22:52, 4 January 2013

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


  • (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.
  • a well organized hierarchical config is easier to read and maintain
  • easily accessed inline/onboard help (syntax and reference) is a GOOD thing
  • 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.

Reference Links