Project rockhammer
Jump to navigation
Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
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.
- 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.