Jump to navigation Jump to search
- 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
- (early) pf for filtering, NAT, filter-forwarding, etc.
- (late) carp for redundancy (failover/load balancing)?
- same platform for any hardware combination
- (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.
- 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)
- 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
- 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.