Difference between revisions of "Project rockhammer"
Jump to navigation
Jump to search
(add more notes) |
m (6 revisions) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 35: | Line 35: | ||
= Lessons Learned Elsewhere = | = Lessons Learned Elsewhere = | ||
* "commit confirmed": best to avoid hosing oneself. | * "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 | * 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. | * having a real onboard editor, and valid [configurable] line editing makes people happy. | ||
| Line 42: | Line 44: | ||
= Misc Notes = | = 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. | * 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 = | ||
| + | * [http://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/ OpenBSD rdomain tutorial @ packetmischief.ca] | ||
Latest revision as of 21: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
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.